7
editací
→Representing the number[edit]
značka: editace z Vizuálního editoru |
značka: editace z Vizuálního editoru |
||
|
source http://cpansearch.perl.org/src/ZEFRAM/Time-UTC-Now-0.008/lib/Time/UTC/Now.xs
====
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.
zdroj http://www.timeanddate.com/time/leap-seconds-background.html
===
Čí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 [https://cs.wikipedia.org/wiki/Probl%C3%A9m_roku_2038]".
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.<sup>[4]</sup> 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".<sup>[5]</sup>
The User Manual also commented that "the chronologically-minded user will note that 2<sup>32</sup> sixtieths of a second is only about 2.5 years". Because of this limited range, the epoch was redefined more than once,<sup>[''citation needed'']</sup> 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 <tt>time_t</tt> 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,<sup>[''citation needed'']</sup> 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.
{{překlad|en|Unix time|624869346}}
| |||