Unixový čas

Unixový čas (nebo také POSIX nebo Epoch time) je systém pro popisování času, definovaných jako počet sekund uplynulých od okamžiku 00:00:00 (Epocha Unixu) koordinovaného světového času (UTC). Unixová epocha byla určena na čtvrtek 1. 1. 1970 (přestupné sekundy nebyly započítány). Tento systém je používán nejen v systémech založených na linuxu a popisu systémových souborů. Díky svému přístupu, kdy počítá přestupné sekundy se nejedná ani o lineární reprezentaci času, ani o reprezentaci koordinovaného světového času, který tyto sekundy nezohledňuje. Zjistit aktuální linuxový čas můžeme na většině linuxových systémů zadáním date +%s do příkazového řádku.

Definice

Unixový čas je tvořen dvěma vrstvami kódu, jejichž oddělení těchto může být velmi užitečné. První vrstva kóduje časové okamžiky jako skalární reálné číslo, druhá jako posloupnost bitů nebo decilmálních číslic. Unixový čas přejímá standardy UTC a dělí čas každého dne podle gregoriánského kalendáře do sekund, minut a hodin. Narozdíl od UTC ale nezohledňuje přestupné sekundy, tím pádem ztrácí synchronicitu se zemskou rotací, tuto vlastnost přebírá od Mezinárodního atomového času (TAI). Rotace Země se totiž zpomaluje, proto by bylo k udržení synchronicity nutné přičíst zhruba sekundu každý rok a půl.

Unixový čas je jednoduché číslo, které narůstá o jednu jednotku každou sekundu, funguje tedy bez členění na roky, měsíce nebo dny, které jsou potřebné pro vyjadřování času lidmi. Moderní unixové systémy založené na UTC počítají SI sekundy, tyto sekundy pak 86400 - tedy na dny.

Unix epoch je čas 00:00:00 UTC k 1.1.1970 (neboli 1970-01-01T00:00:00Z ISO 8601). Problém je, že UTC v současné formě existuje až od roku 1972.

Reprezentace času jedním číslem

Unixový čas i čas Unix epoch narůstají každým dnem o 86400, to znamená, že datum 2004-09-16T00:00:00Z, 12677 dní po 1.1.1970 je Unixovém čase 12677 x 86400 = 1095292800. Stejně by se vypočítaly i hodnoty dat před začátkem odpočítávání, jediným rozdílem by bylo záporné znaménko před číslem.

Během každého dne je Unixový čas vypočítáván z počtu dosud uplynulých sekund do předešlé půlnoci a připočítává se počet sekund uplynulých daný den.

Výše zmíněné schéma znamená, že normální UTC den trvá 86400 sekund, V následující tabulce je znázorněn TAI, UTC a Unixový čas v okamžicích kolem půlnoci. V jednotlivých sloupcích můžeme pozorovat rozdíly mezi časovými modely. Pro připomenutí, Mezinárodní atomový čas (TAI) není synchronizovaný s rotací Země. V září 2004 byl rozdíl mezi TAI a UTC 32 sekund. K UTC bylo celkem tou dobou připočteno právě těchto 32 přechodných sekund.

Unixový čas přes půlnoc 17.9.2004

TAI (17.9.2004)	UTC (16 na 17 září 2004)	Unixový čas
2004-09-17T00:00:30.75	2004-09-16T23:59:58.75	1 095 379 198.75
2004-09-17T00:00:31.00	2004-09-16T23:59:59.00	1 095 379 199.00
2004-09-17T00:00:31.25	2004-09-16T23:59:59.25	1 095 379 199.25
2004-09-17T00:00:31.50	2004-09-16T23:59:59.50	1 095 379 199.50
2004-09-17T00:00:31.75	2004-09-16T23:59:59.75	1 095 379 199.75
2004-09-17T00:00:32.00	2004-09-17T00:00:00.00	1 095 379 200.00
2004-09-17T00:00:32.25	2004-09-17T00:00:00.25	1 095 379 200.25
2004-09-17T00:00:32.50	2004-09-17T00:00:00.50	1 095 379 200.50
2004-09-17T00:00:32.75	2004-09-17T00:00:00.75	1 095 379 200.75
2004-09-17T00:00:33.00	2004-09-17T00:00:01.00	1 095 379 201.00
2004-09-17T00:00:33.25	2004-09-17T00:00:01.25	1 095 379 201.25

Když se do UTC času promítne přechodná sekunda, to znamená, že se nejedná o standardní den, ale o den, který nemá přesně 86400 sekund. Nyní existují 2 scénária. Jedná se o sekundu pouitivní, to znamená, že se zemská rotace zpomalila, v tomto případě je přestupná sekunda vložena do času UTC a Unixový čas pokračuje v počítání, ale jakmile skončí počítání vložené přestupné sekundy, sníží své počítadlo o 1. Druhou možností je, že je přestupná sekunda negativní - zemská rotace se zrychlila a k udržení synchronicity je od UTC času odečtena 1 sekunda. V momentě, kdy je v UTC vymazána sekunda, počítadlo Unixového času přičte jednu jednotku. Přičítání nebo odčítání těchto přestupných sekund probíhá vždy o půlnoci.

Následující ukázka zobrazuje situaci v systému POSIX na konci roku 1998, kdy je do UTC vložena přechodná sekunda

TAI (1.1.1999)	UTC (31.12.1998 na 1.1.1999)	Unixový čas
1999-01-01T00:00:29.75	1998-12-31T23:59:58.75	915 148 798.75
1999-01-01T00:00:30.00	1998-12-31T23:59:59.00	915 148 799.00
1999-01-01T00:00:30.25	1998-12-31T23:59:59.25	915 148 799.25
1999-01-01T00:00:30.50	1998-12-31T23:59:59.50	915 148 799.50
1999-01-01T00:00:30.75	1998-12-31T23:59:59.75	915 148 799.75
1999-01-01T00:00:31.00	1998-12-31T23:59:60.00	915 148 800.00
1999-01-01T00:00:31.25	1998-12-31T23:59:60.25	915 148 800.25
1999-01-01T00:00:31.50	1998-12-31T23:59:60.50	915 148 800.50
1999-01-01T00:00:31.75	1998-12-31T23:59:60.75	915 148 800.75
1999-01-01T00:00:32.00	1999-01-01T00:00:00.00	915 148 800.00
1999-01-01T00:00:32.25	1999-01-01T00:00:00.25	915 148 800.25
1999-01-01T00:00:32.50	1999-01-01T00:00:00.50	915 148 800.50
1999-01-01T00:00:32.75	1999-01-01T00:00:00.75	915 148 800.75
1999-01-01T00:00:33.00	1999-01-01T00:00:01.00	915 148 801.00
1999-01-01T00:00:33.25	1999-01-01T00:00:01.25	915 148 801.25

Všimněte si, že když se objeví přestupná sekunda (např. je přestupná sekunda vložena = pozitivní přestupná sekunda) Unixový čas zopakuje své hodnoty. Například číslo 915148800.50 je nejasným časovým otiskem - může odkazovat buď na čas během přestupné sekundy a nebo na vteřinu potom - vteřinu a půl po půlnoci času UTC. V teoretickém případě se může naskytnou negativní přestupná sekunda (např. přestupná sekunda je vymazána) - žádná nejednoznačnost není způsobena, ale několik hodnot Unixového času by neukazovalo na žádný okamžik.

Unixové hodiny jsou často implementovány s jiným způsobem řešení přestupných sekund - Network Time Protokol (NTP). Toto řešení podléhá systému, které neodpovídá POSIX standardu. V následující sekci

A Unix clock is often implemented with a different type of positive leap second handling associated with the Network Time Protocol (NTP). This yields a system that does not conform to the POSIX standard. See the section below concerning NTP for details.

Pokud se budeme zabývat časovým úsekem, který nebude obsahovat žádné UTC přestupné sekundy, rozdíl mezi dvěma Unixovými časy bude roven počtu sekund mezi těmito časovými body. Jakmile se ale nějaká přestupná sekunda objeví, náš výsledek nebude správně. V případech, kdy bude potřeba takové přesnosti, že rozdíl v řádech několika sekund nebude zanedbatelný, budeme muset náš výpočet upravit podle tabulky přestupných vteřin, nebo raději zvolit pro práci jiný způsob kódování času, který podobným problémem netrpí.

Unixový čas je jednoduše převeditelný na UTC celočíselným dělením 86400. Výsledkem bude počet dní uplynulých od Unixové Epochy a zbytek je počet sekund ulynulých z již započatého dne. Pokud budeme mít číslo Unixového času odkazující právě na pozitivní přestupnou sekundu, algoritmus ho vyhodnotí jako čas těsně po půlnoci. Pokud budeme mít negativní sekundu, výsledkem bude neexistující UTC čas.

Nesychronní síťový čas v protokolu

Obecně jsou Millsovy unixové hodiny implementovány se schopností ignorovat přestupné sekundy. Unixový čas se automaticky sníží tam, kde se objevila pozitivní přestupná sekunda a zvýší tam, kde se objevila negativní. Toto podle Millse usnadňuje implementaci.

non-synchronous Mills-style Unix clock
across midnight when a UTC leap second is inserted on 1 January 1999

TAI (1 January 1999)	UTC (31 December 1998 to 1 January 1999)	state	Unix clock
1999-01-01T00:00:29.75	1998-12-31T23:59:58.75	TIME_INS	915 148 798.75
1999-01-01T00:00:30.00	1998-12-31T23:59:59.00	TIME_INS	915 148 799.00
1999-01-01T00:00:30.25	1998-12-31T23:59:59.25	TIME_INS	915 148 799.25
1999-01-01T00:00:30.50	1998-12-31T23:59:59.50	TIME_INS	915 148 799.50
1999-01-01T00:00:30.75	1998-12-31T23:59:59.75	TIME_INS	915 148 799.75
1999-01-01T00:00:31.00	1998-12-31T23:59:60.00	TIME_INS	915 148 800.00
1999-01-01T00:00:31.25	1998-12-31T23:59:60.25	TIME_OOP	915 148 799.25
1999-01-01T00:00:31.50	1998-12-31T23:59:60.50	TIME_OOP	915 148 799.50
1999-01-01T00:00:31.75	1998-12-31T23:59:60.75	TIME_OOP	915 148 799.75
1999-01-01T00:00:32.00	1999-01-01T00:00:00.00	TIME_OOP	915 148 800.00
1999-01-01T00:00:32.25	1999-01-01T00:00:00.25	TIME_WAIT	915 148 800.25
1999-01-01T00:00:32.50	1999-01-01T00:00:00.50	TIME_WAIT	915 148 800.50
1999-01-01T00:00:32.75	1999-01-01T00:00:00.75	TIME_WAIT	915 148 800.75
1999-01-01T00:00:33.00	1999-01-01T00:00:01.00	TIME_WAIT	915 148 801.00
1999-01-01T00:00:33.25	1999-01-01T00:00:01.25	TIME_WAIT	915 148 801.25

Pokud se zaměříme na stavovou proměnnou, která jednoznačně indikuje v jakém stavu je .

Možnosti hodnot neznámé leap second state jsou:
 *   TIME_OK:  normální, žádná přechodná sekunda v dohledu
 *   TIME_INS:  přechodná sekunda bude vložena na konci tohoto dne ( případě negativní přechodné sekundy )
 *   TIME_DEL: přechodná sekunda bude vymazána na konci tohoto dne ( případě pozitivní přechodné sekundy )
 *   TIME_OOP: tato sekunda je přechodná, přechodná sekunda se vkládá
 *   TIME_WAIT: přechodná sekunda se objevila v nedávné minulosti

source http://cpansearch.perl.org/src/ZEFRAM/Time-UTC-Now-0.008/lib/Time/UTC/Now.xs

metoda založená na TAI

Další, mnohem méně vídanou vyriantou sledování Unixového času je ta, která používá jako základ výpočtu TAI. Některé linuxové systémy mohou být nakonfigurovány takto. Je to proto, že každý TAI den má přesně 86400 sekund a neexistují zde přechodné vteřiny, proto se jedná o čistě lineární součet sekund od 1970-01-01T00:00:00 TAI. To dělá počty s časovými úseky mnohem jednodušší. Hodnoty v tomto systému nevykazují nejednoznačnosti, s jakými se u striktně POSIX a NTP systémů setkáváme.

V případě nutnosti konverze tohoto pseudo-Unixového do UTC času ale budeme opět potřebovat tabulku přechodných sekund. To je podobné způsobu, jako když chceme převádět Unixový čas do místního času - je nutné zohlednit časová pásma. Databáze IANA obsahuje informace o přechodných sekundách. Organizace IANA také uvolňuje kód umožnující převody mezi TAI časovými otisky a lokálními časy. Problematické jsou akorát převody času před 1.1.1970, kdy Unixový čas nabývá záporných hodnot (popsáno níže).

TAI je na první pohled podobný Unixovému času, ale není totožný. TAI definuje vteřinu jinak než POSIX, na kterém je Unixový čas založen. TAI definuje sekundu jako čas, který je potřeba k oscilaci atomu Cesia 133 k vykonání 9 192 631 770 oscilací. Tato metoda využívaná v atomových hodinách je charakterizována velmi minimálními odchylkami, kdežto zemská rotace, na které je založeno UTC a POSIX, tím pádem i Unixový čas, má odchylky daleko výraznější.

zdroj http://www.timeanddate.com/time/leap-seconds-background.html

Číselná reprezentace

Číselná reprezentace Unixového času může nabývat mnoha podob, které umožňují vyjádřit číslo. Někdy to mohou být jednoduché číslice v textovém poli (string), jejihž zpracování je provázeno zanedbatelnými problémy. Velmi obvyklá je ale binární reprezentace těchto hodnot.

Standard Unix time_t(údaj reprezentující konkrétní okamžik) se ukládá jako integer - tradičně 32 bitový. 32 bitů dokáže popsat čas v rozmezí 136 let. Počáteční čas, který může být takto vyjádřen je 13.12.1901 a konečný je 19.1.2038. V sekundě po 03:14:07 UTC 2038-01-19 dojde k přetečení proměnné. Tento problém má název "problém roku 2038 [1]".

V některých novějších operačních systémech je time_t rozšířen na 64 bitů. To už stačí k pokrytí časového rozpětí od vzniku vesmíru po přibližně rok 293 biliónů.

Původní rozepře, zda by time_t měl být podepsaný nebo nepodepsaný integer (pokud je nepodepsaný, první bit také vyjadřuje hodnotu, ale pak má integer pouze kladné hodnoty) byla vyřešena v prospěch podepsaného integeru, což umožňuje vyjadřovat hodnoty před rokem 1970. Softwarová vývojářská patforma pro verzi 6 QNX opračního systému pracuje s nepodepsaným 32-bitovým integerem, což odsouvá problém přetečení o 68 let, nicméně, jak již zmíněno, je nemožné vyjádřit čas před rokem 1970 .

Apecifikace POSIX a Open Group Unix zahrnují standardní knihovnu C, která zahrnuje časové typy a funkce definované v hlavičkovém souboru <time.h>. ISO C standardu nařizuje, že time_t musí být aritmetického typu, ale žádná další specifika.

UTC základ

Současná verze UTC s přechodnými sekundami je definována až po 1.1.1972. Předtím, po 1.1.1961 existovala starší verze UTC, která trpěla mnoha nedostatky - užívala například jiné, než SI sekundy. Před rokem 1961 nebyl standardizován světový čas a před rokem 1958 standardně neexistovalo měření času atomovými hodinami. Čas se určoval na základě aproximace výpočtů zemské rotace.

Přesná definice Unixového času je jako derivátu času UTC je formálně v pořádku pouze pokud bereme v potaz současnou formu UTC. Naštěstí je fakt, že Unixová epocha předchází vzniku současné podoby UTC neovlivňuje současné užití______- Počet dnů od 1.1.1970 (Unixová epocha) do 1.1.1972 (vznik současné podoby UTC) je známý, a to je jediné, co je důležité pro Unixový čas.

Význam časových hodnot menších než +63 072 000 (před 1.1.1972) není přesně definován, ale přibližně se dají spočítat podle GMT. Počítače v té době měly zřídka hodiny schopné rozlišovat čas s přesností větší, než 1 sekunda. Unixový čas se tedy nehodí pro reprezentaci momentů před rokem 1972 s požadovanou přesností větší než 1 sekunda.

As of 2009, the possibility of ending the use of leap seconds in civil time is being considered.^[4] A likely means to execute this change is to define a new time scale, called "International Time", that initially matches UTC but thereafter has no leap seconds, thus remaining at a constant offset from TAI. If this happens, it is likely that Unix time will be prospectively defined in terms of this new time scale, instead of UTC. Uncertainty about whether this will occur makes prospective Unix time no less predictable than it already is: if UTC were simply to have no further leap seconds the result would be the same.

History[edit]

The earliest versions of Unix time had a 32-bit integer incrementing at a rate of 60 Hz, which was the rate of the system clock on the hardware of the early Unix systems. The value 60 Hz still appears in some software interfaces as a result. The epoch also differed from the current value. The first edition Unix Programmer's Manual dated 3 November 1971 defines the Unix time as "the time since 00:00:00, 1 January 1971, measured in sixtieths of a second".^[5]

The User Manual also commented that "the chronologically-minded user will note that 2³² sixtieths of a second is only about 2.5 years". Because of this limited range, the epoch was redefined more than once,^{[citation needed]} before the rate was changed to 1 Hz and the epoch was set to its present value. This yielded a range of about 136 years, though with more than half the range in the past (see discussion of signedness above).

As indicated by the definition quoted above, the Unix time scale was originally intended to be a simple linear representation of time elapsed since an epoch. However, there was no consideration of the details of time scales, and it was implicitly assumed that there was a simple linear time scale already available and agreed upon. Indeed, the first edition manual's definition doesn't even specify which time zone is used. Several later problems, including the complexity of the present definition, result from Unix time having been defined gradually by usage rather than fully defined from the outset.

When POSIX.1 was written, the question arose of how to precisely define time_t in the face of leap seconds. The POSIX committee considered whether Unix time should remain, as intended, a linear count of seconds since the epoch, at the expense of complexity in conversions with civil time or a representation of civil time, at the expense of inconsistency around leap seconds. Computer clocks of the era were not sufficiently precisely set to form a precedent one way or the other.

The POSIX committee was swayed by arguments against complexity in the library functions,^{[citation needed]} and firmly defined the Unix time in a simple manner in terms of the elements of UTC time. Unfortunately, this definition was so simple that it didn't even encompass the entire leap year rule of the Gregorian calendar, and would make 2100 a leap year.

The 2001 edition of POSIX.1 rectified the faulty leap year rule in the definition of Unix time, but retained the essential definition of Unix time as an encoding of UTC rather than a linear time scale. Also, since the mid-1990s computer clocks have been routinely set with sufficient precision for this to matter, and they have most commonly been set using the UTC-based definition of Unix time. This has resulted in considerable complexity in Unix implementations, and in the Network Time Protocol, to execute steps in the Unix time number whenever leap seconds occur.

V tomto článku byl použit překlad textu z článku Unix time na anglické Wikipedii.