Unixový čas: Porovnání verzí

Přidáno 5 455 bajtů ,  před 7 lety
probíhající překlad
(pokračující překlad)
(probíhající překlad)
 
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ý cas v okamžicích kolem punoci. V jednotlivých sloupcích mužeme pozorovat rozdíly mezi časovými modely. Pro připomenutí, Mezinárodní atomový čas (TAI) je synchronizovaný s rotací Země - zhruba jednou ročne se k němu připočítívá přestupná sekunda. V září 2004 byl rozdíl mezi TAI a UTC 32 sekund. Unixový čas přes půlnoc 17.9.2004
{|
|+Unixový čas přes půlnoc 17.9.2004
!TAI (17 September 2004)
!UTC (16 to 17 September 2004)
!Unix time
|-
|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<br>
<br>
|}
When a leap second occurs, so that the UTC day is not exactly 86400 seconds long, a discontinuity occurs in the Unix time number. The Unix time number increases by exactly 86400 each day, regardless of how long the day is. When a leap second is deleted,<sup>[note 5]</sup> the Unix time number jumps up by 1 where the leap second was deleted, which is the end of the day. When a leap second is inserted,<sup>[note 6]</sup> the Unix time number increases continuously during the leap second, during which time it is more than 86400 seconds since the start of the current day, and then jumps back by 1 at the end of the leap second, which is the start of the next day. For example, this is what happened on strictly conforming POSIX.1 systems at the end of 1998:
{|
|+Unix time across midnight<br>
when a UTC leap second is inserted on 1 January 1999
!TAI (1 January 1999)
!UTC (31 December 1998 to 1 January 1999)
!Unix time
|-
|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í kladná přestupná sekunda (např. je přestupná sekunda vložena) 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. Vteoretické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.
 
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.
 
When dealing with periods that do not encompass a UTC leap second, the difference between two Unix time numbers is equal to the duration in seconds of the period between the corresponding points in time. This is a common computational technique. However, where leap seconds occur, such calculations give the wrong answer. In applications where this level of accuracy is required, it is necessary to consult a table of leap seconds when dealing with Unix times, and it is often preferable to use a different time encoding that does not suffer this problem.
 
A Unix time number is easily converted back into UTC by taking the quotient and modulus of the Unix time number, modulo 86400. The quotient is the number of days since the epoch, and the modulus is the number of seconds since midnight UTC on that day.<sup>[note 7]</sup> If given a Unix time number that is ambiguous due to a positive leap second, this algorithm interprets it as the time just after midnight. It never generates a time that is during a leap second. If given a Unix time number that is invalid due to a negative leap second, it generates an equally invalid UTC time. If these conditions are significant, it is necessary to consult a table of leap seconds to detect them.
 
{{překlad|en|Unix time|624869346}}