Encoding Time As A Number
Unix time is a single signed integer number which increments every second, without requiring the calculations to determine year, month, day of month, hour and minute required for intelligibility to humans. Modern Unix time is based on UTC, which counts time using SI seconds, and breaks up the span of time into days almost always 86 400 s long, but due to leap seconds occasionally 86 401 s this keeps the days synchronized with the rotation of the Earth as per Universal Time.
The Unix epoch is the time 00:00:00 UTC on 1 January 1970 (or 1970-01-01T00:00:00Z ISO 8601). There is a problem with this definition, in that UTC did not exist in its current form until 1972; this issue is discussed below. For brevity, the remainder of this section uses ISO 8601 date format, in which the Unix epoch is 1970-01-01T00:00:00Z.
The Unix time number is zero at the Unix epoch, and increases by exactly 86 400 per day since the epoch. Thus 2004-09-16T00:00:00Z, 12 677 days after the epoch, is represented by the Unix time number 12 677 × 86 400 = 1 095 292 800. This can be extended backwards from the epoch too, using negative numbers; thus 1957-10-04T00:00:00Z, 4 472 days before the epoch, is represented by the Unix time number -4 472 × 86 400 = -386 380 800.
Within each day, the Unix time number is as calculated in the preceding paragraph at midnight UTC (00:00:00Z), and increases by exactly 1 per second since midnight. Thus 2004-09-16T17:55:43.54Z, 64 543.54 s since midnight on the day in the example above, is represented by the Unix time number 1 095 292 800 + 64 543.54 = 1 095 357 343.54. On dates before the epoch the number still increases, thus becoming less negative, as time moves forward.
The above scheme means that on a normal UTC day, of duration 86 400 s, the Unix time number changes in a continuous manner across midnight. For example, at the end of the day used in the examples above, the time representations progress as follows:
| 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 |
When a leap second occurs, so that the UTC day is not exactly 86 400 s long, a discontinuity occurs in the Unix time number. The Unix time number increases by exactly 86 400 each day, regardless of how long the day is. When a leap second is deleted, 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, the Unix time number increases continuously during the leap second, during which time it is more than 86 400 s 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:
| 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 |
Observe that when a positive leap second occurs (i.e., when a leap second is inserted) the Unix time numbers repeat themselves. The Unix time number 915 148 800.50 is ambiguous: it can refer either to the instant in the middle of the leap second, or to the instant one second later, half a second after midnight UTC. In the theoretical case when a negative leap second occurs (i.e., when a leap second is deleted) no ambiguity is caused, but instead there is a range of Unix time numbers that do not refer to any point in time at all.
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 86 400. The quotient is the number of days since the epoch, and the modulus is the number of seconds since midnight UTC on that day. 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.
There are numerous online utilities available to convert between a date and a Unix timestamp.
Read more about this topic: Unix Time, Definition
Famous quotes containing the words time and/or number:
“My time has come.
There are twenty people in my belly,
there is a magnitude of wings,
there are forty eyes shooting like arrows,
and they will all be born.
All be born in the yellow wind.”
—Anne Sexton (1928–1974)
“How often should a woman be pregnant? Continually, or hardly ever? Or must there be a certain number of pregnancy anniversaries established by fashion? What do you, at the age of forty-three, have to say on the subject? Is it a fact that the laws of nature, or of the country, or of propriety, have ordained this time of life for sterility?”
—Philip Dormer Stanhope, 4th Earl Chesterfield (1694–1773)