Unix time
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 +63072000 (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 (divided down from the actual CPU cycle speed of ~1.8 MHz). 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 232 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.
In 2004 POSIX added[citation needed] new interfaces making several different time scales available to programs, splitting up the many uses to which Unix times have traditionally been put. As the new POSIX time interfaces have not been fully deployed by the programs that may actually have a use for them, the POSIX time interface change has gone unnoticed.
[
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. 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.[1] [2]
[
See also
[
Notes
[
External links
- Unix Programmer's Manual, first edition
- Online tool to convert from Unix time to human-friendly representations, and back
- Unixtime online: Convert unix time to plain English, and vice-versa!
- Unixtime timestamp generator
- All timestamp numbers
- personal account of the POSIX decisions by Landon Curt Noll
- BASH: Convert Unix Timestamp to a Date
- Convert a UNIX timestamp to a readable format
- Windows Command Line Tool convert unix timestamp to readable date/time
For more information review our copyright contact and privacy policy.