Unixový čas: Porovnání verzí

Přidáno 4 053 bajtů ,  před 7 lety
source http://cpansearch.perl.org/src/ZEFRAM/Time-UTC-Now-0.008/lib/Time/UTC/Now.xs
 
==== TAI-basedmetoda variant[edit]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.
 
zdroj http://www.timeanddate.com/time/leap-seconds-background.html
 
=== RepresentingČíselná the number[edit]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.
A Unix time number can be represented in any form capable of representing numbers. In some applications the number is simply represented textually as a string of decimal digits, raising only trivial additional problems. However, certain binary representations of Unix times are particularly significant.
 
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]".
The standard Unix <tt>time_t</tt> (data type representing a point in time) is a signed integer data type, traditionally of 32 bits (but see below), directly encoding the Unix time number as described in the preceding section. Being 32 bits means that it covers a range of about 136 years in total. The minimum representable time is 1901-12-13, and the maximum representable time is 2038-01-19. The second after 03:14:07 UTC 2038-01-19 this representation overflows. This milestone is anticipated with a mixture of amusement and dread; see year 2038 problem.
 
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ů.
In some newer operating systems, <tt>time_t</tt> has been widened to 64 bits. In the negative direction, this goes back more than twenty times the age of the universeand in the positive direction for approximately 293 billion years.
 
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 .
There was originally some controversy over whether the Unix <tt>time_t</tt> should be signed or unsigned. If unsigned, its range in the future would be doubled, postponing the 32-bit overflow (by 68 years). However, it would then be incapable of representing times prior to 1970.<sup>[note 8]</sup> The consensus is for <tt>time_t</tt> to be signed, and this is the usual practice. The software development platform for version 6 of the QNX operating system has an unsigned 32-bit <tt>time_t</tt>, though older releases used a signed type.
 
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.
The POSIX and Open Group Unix specifications include the C standard library, which includes the time types and functions defined in the <time.h> header file. The ISO C standard states that <tt>time_t</tt> must be an arithmetic type, but does not mandate any specific type or encoding for it.
 
=== UTC základ ===
Unix has no tradition of directly representing non-integer Unix time numbers as binary fractions. Instead, times with sub-second precision are represented usingcomposite data types that consist of two integers, the first being a <tt>time_t</tt> (the integral part of the Unix time), and the second being the fractional part of the time number in millionths (in <tt>struct timeval</tt>) or billionths (in <tt>struct timespec</tt>). These structures provide a decimal-based fixed-point data format, which is useful for some applications, and trivial to convert for others.
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}}