Unix time

Unix time, or POSIX time, is a system for describing points in time, defined as the number of seconds elapsed since midnight Coordinated Universal Time (UTC) of January 1 1970, not counting leap seconds. It is widely used not only on Unix-like operating systems but also in many other computing systems. It is neither a linear representation of time nor a true representation of UTC (though it is frequently mistaken for both) as the times it represents are UTC but it has no way of representing UTC leap seconds (e.g. 1998-12-31 23:59:60). selfref|1=

Example: #expr:(age in days|1970|01|01*24*60*60)+((CURRENTHOUR*60*60)+(CURRENTMINUTE*60)+(CURRENTSECOND)) () This was the Unix time when this page was last generated.

Definition

There are two layers of encoding that make up Unix time, and they can be usefully separated. The first layer encodes a point in time as a scalar real number, and the second encodes that number as a sequence of bits or in some other manner.

Encoding time as a number

Modern Unix time is based strictly on UTC. UTC counts time using SI seconds, and breaks up the span of time into days. UTC days are mostly 86400 s long, but due to "leap seconds" are occasionally 86401 s and could be 86399 s long (though the latter option has never been used as of January 2008); this is in order to keep the days synchronised with the rotation of the Earth (or Universal Time). As is standard with UTC, this article will label days using the Gregorian calendar, and count times within each day in hours, minutes, and seconds. Some of the examples will also show TAI, another time scheme, which uses the same seconds and is displayed in the same format as UTC, but has every day exactly 86400 s long, making no attempt to stay synchronised with the Earth's rotation.

The Unix epoch is the time 00:00:00 UTC on January 1 1970. 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 will use 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, 4472 days before the epoch, is represented by the Unix time number -4472 × 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 like this:

This can be decoded properly by paying attention to the leap second state variable, which unambiguously indicates whether the leap has been performed yet. The state variable change is synchronous with the leap.

A similar situation arises with a negative leap second, where the second that is skipped is slightly too late. Very briefly the system shows a nominally impossible time number, but this can be detected by the TIME_DEL state and corrected.

In this type of system the Unix time number violates POSIX around both types of leap second. Collecting the leap second state variable along with the time number allows for unambiguous decoding, so the correct POSIX time number can be generated if desired, or the full UTC time can be stored in a more suitable format.

The decoding logic required to cope with this style of Unix clock would also correctly decode a hypothetical POSIX-conforming clock using the same interface. This would be achieved by indicating the TIME_INS state during the entirety of an inserted leap second, then indicating TIME_WAIT during the entirety of the following second while repeating the seconds count. This requires synchronous leap second handling. This is probably the best way to express UTC time in Unix clock form, via a Unix interface, when the underlying clock is fundamentally untroubled by leap seconds.

International Atomic Time-based variant

Another, much rarer, non-conforming variant of Unix time keeping involves encoding International Atomic Time (TAI) rather than UTC. Because TAI has no leap seconds, and every TAI day is exactly 86 400 s long, this encoding is actually a pure linear count of seconds elapsed since 1970-01-01T00:00:00 TAI. This makes time interval arithmetic much easier. Time values from these systems do not suffer the ambiguity that strictly conforming POSIX systems or NTP-driven systems have.

In these systems it is necessary to consult a table of leap seconds in order to correctly convert between UTC and the pseudo-Unix-time representation. This resembles the manner in which time zone tables must be consulted in order to convert to and from civil time. The leap second table must be updated (from the published leap second bulletins) more frequently than the time zone tables, because leap seconds occur at shorter notice than changes to daylight saving time rules. (A standard Unix time system must similarly consult a leap second table to convert to and from TAI, but this is a much rarer requirement.) Conversion also runs into definitional problems prior to the 1972 commencement of the current form of UTC (see the later section about UTC).

This TAI-based system, despite its superficial resemblance, is not Unix time. It encodes times with significantly different values from the POSIX time values, and does not have the simple mathematical relationship to UTC that is mandated by POSIX.

Representing the number

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 issues. However, there are certain binary representations of Unix times that are of particular significance.

The standard Unix time_t (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 integer means that it has a resolution of one second; many Unix applications therefore handle time only to that resolution. Being 32 bits (of which one bit is the sign bit) 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-18. At 2038-01-18 this representation will overflow. This milestone is anticipated with a mixture of amusement and dread; see year 2038 problem.

In some newer operating systems, time_t has been widened to 64 bits. In the negative direction, this goes back more than twenty times the age of the universe, and so suffices. In the positive direction, whether the approximately 293 billion representable years is truly sufficient depends on the ultimate fate of the universe, but it is certainly adequate for most practical purposes.

There was originally some controversy over whether the Unix time_t 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. Dennis Ritchie, when asked about this issue, said that he hadn't thought very deeply about it, but was of the opinion that the ability to represent all times within his lifetime would be nice. (Ritchie's birth time is around Unix time -893,400,000.) The consensus, and universal practice, is for time_t to be signed.

The POSIX and Open Group Unix specifications include the ISO C standard library, which includes the time types and functions defined in the <time.h> header file. The ISO C standard states that time_t must be an arithmetic type, but does not mandate any specific type or encoding for it.

Unix has no tradition of directly representing non-integer Unix time numbers as binary fractions. Instead, times with sub-second precision are represented using compound data types that consist of two integers, the first being a time_t (the integral part of the Unix time), and the second being the fractional part of the time number in millionths (in struct timeval) or billionths (in struct timespec). These structures provide a decimal-based fixed-point data format, which is useful for some applications, and trivial to convert for others.

UTC basis

The present form of UTC, with leap seconds, is defined only from January 1 1972 onwards. Prior to that, since January 1 1961 there was an older form of UTC in which not only were there occasional time steps, which were by non-integer numbers of seconds, but also the UTC second was slightly longer than the SI second, and periodically changed, in order to continuously approximate the Earth's rotation. Prior to 1961 there was no UTC, and prior to 1958 there was no widespread atomic timekeeping; in these eras, some approximation of GMT (based directly on the Earth's rotation) was used instead of an atomic timescale.

The precise definition of Unix time as an encoding of UTC is only controversially applicable to the present form of UTC. Fortunately, the fact that the Unix epoch predates the start of this form of UTC does not affect its use in this era: the number of days from January 1 1970 (the Unix epoch) to January 1 1972 (the start of UTC) is not in question, and the number of days would be all that is significant to Unix time, if Unix time were not counted in seconds. The root of the problem is that the day, or nychthemeron, is a continuously varying "unit" of time, ever growing gradually longer because of tidal drag caused by interaction between the Moon, the Earth's oceans, and the rotating Earth itself. As a result, the current day is 86400.002 seconds long (and increasing), a fact which UTC takes into account, but which Unix (POSIX) time as currently defined does not.

The meaning of Unix time values below [phone] (i.e., prior to January 1 1972) is not precisely defined. The basis of such Unix times is best understood to be an unspecified approximation of GMT. Computers of that era rarely had clocks set sufficiently accurately to provide meaningful sub-second timestamps in any case. Unix time is not a suitable way to represent times prior to 1972 in applications requiring sub-second precision; such applications must, at least, define which form of UT or GMT they are using.

As of 2004, the possibility of ending the use of leap seconds in civil time is being considered. 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. Reinterpreting Unix time in terms of TAI or GPS time, while more simple in theory, would make a hash of assumptions built into time-handling code written since the 1970s. Such a move would be a replacement of Unix time by a new system, rather than a reinterpretation.

History

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 November 3 1971 defines the Unix time as "the time since 00:00:00, Jan. 1, 1971, measured in sixtieths of a second".

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, before the rate was changed to 1 Hz and the epoch was set to its present value. This yielded a range in excess of 130 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 timezone 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 to start with.

When POSIX.1 was written, in the 1980s (it was published in 1988), the question arose of how to precisely define time_t in the face of leap seconds. Some argued for it to remain, as intended, a linear count of seconds since the epoch, at the expense of complexity in conversions with civil time. Others argued for it to remain, as conflictingly intended, easily interconvertible with the conventional 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, 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, in order to execute steps in the Unix time number whenever leap seconds occur.

Unix time in literature

Vernor Vinge's novel "A Deepness in the Sky" describes a space-faring trading civilization tens of thousands of years (hundreds of gigaseconds) in the future that apparently still uses the Unix epoch, despite the apparent problems that would have arisen with the Unix system following the Year 2038 Problem. It is noted that this epoch is approximately when man first walked on the moon which is what the Qeng Ho mistakenly believe is the basis for their calendar. However, the timekeeping code is layered upon ancient programs including one that is implied to be based on the Unix epoch. [ [http://www.luga.at/mailing-lists/rr/2006/08/msg00001.html LUGA: rr: [rr mature programming environment ] ] [ [http://unixepoch.com The UnixTime Apocalypse] ]

ee also

* time_t
* System time
* Year 2000 problem
* Year 2038 problem

Notes

External links

* [http://cm.bell-labs.com/cm/cs/who/dmr/1stEdman.html Unix Programmer's Manual, first edition]
* [http://www.mail-archive.com/[e-mail]/msg00109.html personal account of the POSIX decisions] by Landon Curt Noll
* [http://antonolsen.com/2006/04/06/bash-convert-unix-timestamp-to-a-date/ BASH: Convert Unix Timestamp to a Date]
* [http://www.4webhelp.net/us/timestamp.php Convert a UNIX timestamp to a readable format]
* [http://www.timestampgenerator.com Generate Unix Timestamps]
* [http://clickbay.de/01_win/wintip/cmd01.htm Windows Command Line Tool] convert unix timestamp to readable date/time