Unix time and User talk:209.68.98.33: Difference between pages

Revision as of 15:41, 21 February 2006

Revision as of 00:52, 21 February 2007

Line 1:

{{SharedIPEDU|GV/WFL BOCES Educational TechnologyService}}

'''Unix time''', or '''POSIX time''', is a system for describing points in [[time]]. It is widely used not only on [[Unix]]-like operating systems but in many other computing systems, including the [[Java programming language]]. It is an encoding of [[Coordinated Universal Time|UTC]], and is sufficiently similar to a linear representation of the passage of time that it is frequently mistaken for one. The main complication is the [[leap second]]s of UTC time.

=== February 2007 ===

==Definition==

[[Image:Information.svg|25px]] Thank you for experimenting with the page [[:Money]] on Wikipedia. Your test worked, and it has been [[Help:Reverting|reverted]] or removed. Please take a look at the [[Wikipedia:Introduction|welcome page]] to learn more about contributing to our encyclopedia. If you would like to experiment, please use the [[Wikipedia:Sandbox|sandbox]]. {{{2|}}}<!-- {{uw-test1}} --> [[User:Sirtrebuchet|Sirtrebuchet]] 16:30, 8 February 2007 (UTC)

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 [[bit]]s or in some other manner.

:''If this is an shared [[IP address]], ignore this warning if you did not make any [[Wikipedia:vandalism|unconstructive]] edits.''

<br />

===Encoding time as a number===

[[Image:Stop hand.svg|30px]] Please stop. If you continue to [[Wikipedia:Vandalism|vandalize]] pages, {{#if:Jacob Riis|as you did {{#if:{{{diff|}}}|with [{{{diff}}} this edit]}} to [[:Jacob Riis]],|{{#if:{{{diff|}}}as you did with [{{{diff}}} this edit],}}}} you will be [[Wikipedia:Blocking policy|blocked]] from editing Wikipedia. <!-- Template:Test3 (Third level warning) --> 20:12, 9 February 2007 (UTC)

[[Image:Stop hand.svg|left|30px]] Welcome to Wikipedia. We invite everyone to contribute constructively to our encyclopedia. Take a look at the [[Wikipedia:Introduction|welcome page]] if you would like to learn more about contributing. However, unconstructive edits{{#if:George Armstrong Custer|, such as those you made to [[:George Armstrong Custer]],}} are considered [[Wikipedia:Vandalism|vandalism]] and immediately reverted. If you continue in this manner you may be '''[[Wikipedia:blocking policy|blocked]] from editing without further warning'''. Please stop, and consider improving rather than damaging the work of others. Thank you. <!-- Template:Blatantvandal (serious warning) --> [[User:Angusmclellan|Angus McLellan]] [[User talk:Angusmclellan|(Talk)]] 13:30, 12 February 2007 (UTC)

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

== Your edits to [[Parkour]] ==

The '''Unix [[epoch (reference date)|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.

[[Image:Stop_hand.svg|left|30px]] This is your '''last warning'''. <br />The next time you [[Wikipedia:Vandalism|vandalize]] a page, {{#if:Parkour|as you did {{#if:{{{diff|}}}|with [{{{diff}}} this edit]}} to [[:Parkour]],|{{#if:{{{diff|}}}|as you did with [{{{diff}}} this edit],}}}} you will be [[Wikipedia:Blocking policy|blocked]] from editing Wikipedia. <!-- Template:Test4 (Fourth level warning) --> --[[User:Inhuman14|<font color="#7299AA">.ιΙ</font><font color="#627A9D"> I</font><font color="#5374A1">n</font><font color="#41669A">hu</font><font color="#235397">man</font><font color="#044197">14</font><font color="#004092"> Ιι.</font>]]^{<small>( [[user_talk:Inhuman14|<font color="#003588">talk</font>]] | [[Special:contributions/Inhuman14|<font color="#000000">contrib</font>]])</small>} 19:35, 13 February 2007 (UTC)

The Unix time number is zero at the Unix epoch, and increases by exactly 86&nbsp;400 per day since the epoch. Thus 2004-09-16T00:00:00Z, 12&nbsp;677 days after the epoch, is represented by the Unix time number 12&nbsp;677 &times; 86&nbsp;400 = 1&nbsp;095&nbsp;292&nbsp;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 &times; 86&nbsp;400 = -386&nbsp;380&nbsp;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&nbsp;543.54&nbsp;s since midnight on the day in the example above, is represented by the Unix time number 1&nbsp;095&nbsp;292&nbsp;800 + 64&nbsp;543.54 = 1&nbsp;095&nbsp;357&nbsp;343.54. On dates before the epoch the number still increases, thus becoming less negative, as time moves forward.

[[Image:Information.svg|25px]] Please do not add unhelpful and non-constructive information to Wikipedia, as you did to [[:Gupta Empire]]. Your edits could be considered [[Wikipedia:Vandalism|vandalism]], and they have been [[Help:Reverting|reverted]]. If you would like to experiment, please use the [[Wikipedia:Sandbox|sandbox]]. {{{2|Thank you.}}}<!-- {{uw-vandalism2}} --> '''''<font color="#FF0000">[[User:Hut 8.5|Hut 8.5]]</font>''''' 17:32, 20 February 2007 (UTC)

The above scheme means that on a normal UTC day, of duration 86&nbsp;400&nbsp;s, the Unix time number changes in a [[continuous function|continuous]] manner across midnight. For example, at the end of the day used in the examples above, the time representations progress like this:

:''If this is a shared [[IP address]], and you didn't make the edit, please ignore this notice''

{{subst4|The She-Bear}} [[User:Goldfritha|Goldfritha]] 00:52, 21 February 2007 (UTC)

{| border="1" cellspacing="0" cellpadding="2"

|+ Unix time across midnight on a normal UTC day

|-

! align="left"|TAI

! align="left"|UTC

! align="right"|Unix time

|-

| align="left"|2004-09-17T00:00:30.75

| align="left"|2004-09-16T23:59:58.75

| align="right"|1&nbsp;095&nbsp;379&nbsp;198.75

|-

| align="left"|2004-09-17T00:00:31.00

| align="left"|2004-09-16T23:59:59.00

| align="right"|1&nbsp;095&nbsp;379&nbsp;199.00

|-

| align="left"|2004-09-17T00:00:31.25

| align="left"|2004-09-16T23:59:59.25

| align="right"|1&nbsp;095&nbsp;379&nbsp;199.25

|-

| align="left"|2004-09-17T00:00:31.50

| align="left"|2004-09-16T23:59:59.50

| align="right"|1&nbsp;095&nbsp;379&nbsp;199.50

|-

| align="left"|2004-09-17T00:00:31.75

| align="left"|2004-09-16T23:59:59.75

| align="right"|1&nbsp;095&nbsp;379&nbsp;199.75

|-

| align="left"|2004-09-17T00:00:32.00

| align="left"|2004-09-17T00:00:00.00

| align="right"|1&nbsp;095&nbsp;379&nbsp;200.00

|-

| align="left"|2004-09-17T00:00:32.25

| align="left"|2004-09-17T00:00:00.25

| align="right"|1&nbsp;095&nbsp;379&nbsp;200.25

|-

| align="left"|2004-09-17T00:00:32.50

| align="left"|2004-09-17T00:00:00.50

| align="right"|1&nbsp;095&nbsp;379&nbsp;200.50

|-

| align="left"|2004-09-17T00:00:32.75

| align="left"|2004-09-17T00:00:00.75

| align="right"|1&nbsp;095&nbsp;379&nbsp;200.75

|-

| align="left"|2004-09-17T00:00:33.00

| align="left"|2004-09-17T00:00:01.00

| align="right"|1&nbsp;095&nbsp;379&nbsp;201.00

|-

| align="left"|2004-09-17T00:00:33.25

| align="left"|2004-09-17T00:00:01.25

| align="right"|1&nbsp;095&nbsp;379&nbsp;201.25

|}

When a [[leap second]] occurs, so that the UTC day is not exactly 86&nbsp;400&nbsp;s long, a [[discontinuity]] occurs in the Unix time number. The Unix time number increases by exactly 86&nbsp;400 each day, regardless of how long the day is. When a leap second is deleted (which has never occurred, as of [[2006]]), the Unix time number jumps up by 1 at the instant where the leap second was deleted from, which is the end of the day. When a leap second is inserted (which has occurred on average once every year and a half), the Unix time number increases continuously during the leap second, during which time it is more than 86&nbsp;400&nbsp;s since the start of the current day, and then jumps down 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]]:

{| border="1" cellspacing="0" cellpadding="2"

|+ Unix time across midnight when a UTC leap second is inserted

|-

! align="left"|TAI

! align="left"|UTC

! align="right"|Unix time

|-

| align="left"|1999-01-01T00:00:29.75

| align="left"|1998-12-31T23:59:58.75

| align="right"|915&nbsp;148&nbsp;798.75

|-

| align="left"|1999-01-01T00:00:30.00

| align="left"|1998-12-31T23:59:59.00

| align="right"|915&nbsp;148&nbsp;799.00

|-

| align="left"|1999-01-01T00:00:30.25

| align="left"|1998-12-31T23:59:59.25

| align="right"|915&nbsp;148&nbsp;799.25

|-

| align="left"|1999-01-01T00:00:30.50

| align="left"|1998-12-31T23:59:59.50

| align="right"|915&nbsp;148&nbsp;799.50

|-

| align="left"|1999-01-01T00:00:30.75

| align="left"|1998-12-31T23:59:59.75

| align="right"|915&nbsp;148&nbsp;799.75

|-

| align="left"|1999-01-01T00:00:31.00

| align="left"|1998-12-31T23:59:60.00

| align="right"|915&nbsp;148&nbsp;800.00

|-

| align="left"|1999-01-01T00:00:31.25

| align="left"|1998-12-31T23:59:60.25

| align="right"|915&nbsp;148&nbsp;800.25

|-

| align="left"|1999-01-01T00:00:31.50

| align="left"|1998-12-31T23:59:60.50

| align="right"|915&nbsp;148&nbsp;800.50

|-

| align="left"|1999-01-01T00:00:31.75

| align="left"|1998-12-31T23:59:60.75

| align="right"|915&nbsp;148&nbsp;800.75

|-

| align="left"|1999-01-01T00:00:32.00

| align="left"|1999-01-01T00:00:00.00

| align="right"|915&nbsp;148&nbsp;800.00

|-

| align="left"|1999-01-01T00:00:32.25

| align="left"|1999-01-01T00:00:00.25

| align="right"|915&nbsp;148&nbsp;800.25

|-

| align="left"|1999-01-01T00:00:32.50

| align="left"|1999-01-01T00:00:00.50

| align="right"|915&nbsp;148&nbsp;800.50

|-

| align="left"|1999-01-01T00:00:32.75

| align="left"|1999-01-01T00:00:00.75

| align="right"|915&nbsp;148&nbsp;800.75

|-

| align="left"|1999-01-01T00:00:33.00

| align="left"|1999-01-01T00:00:01.00

| align="right"|915&nbsp;148&nbsp;801.00

|-

| align="left"|1999-01-01T00:00:33.25

| align="left"|1999-01-01T00:00:01.25

| align="right"|915&nbsp;148&nbsp;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&nbsp;148&nbsp;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.

It is a common mistake to implement a Unix clock with the [[Network Time Protocol]]'s differing handling of positive leap seconds. This yields a system that does not conform to the POSIX standard. See the section below concerning NTP for details.

When dealing with time 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 time 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. (It is important to ensure that the right type of modulus is being calculated when dealing with times before the epoch.) If given a Unix time number that is ambiguous due to a positive leap second, this algorithm will interpret it as the time just after midnight. It will never generate a time that is during a leap second. If given a Unix time number that is invalid due to a negative leap second, it will generate an equally invalid UTC time. If these conditions are significant then it is necessary to consult a table of leap seconds in order to detect them.

====NTP-based variant====

To complicate things, the [[Network Time Protocol]] handles positive leap seconds differently. It has its own numeric time representation, very similar to Unix time but with a different [[epoch (reference date)|epoch date]] and different leap second behaviour. NTP time repeats the second preceding the leap second, rather than the second following the leap second. Unix clocks controlled by NTP are usually implemented by just adding a constant offset to the NTP time, and therefore usually behave like this:

{| border="1" cellspacing="0" cellpadding="2"

|+ NTP-based Unix clock across midnight when a UTC leap second is inserted

|-

! align="left"|TAI

! align="left"|UTC

! align="right"|NTP-based Unix clock

|-

| align="left"|1999-01-01T00:00:29.75

| align="left"|1998-12-31T23:59:58.75

| align="right"|915&nbsp;148&nbsp;798.75

|-

| align="left"|1999-01-01T00:00:30.00

| align="left"|1998-12-31T23:59:59.00

| align="right"|915&nbsp;148&nbsp;799.00

|-

| align="left"|1999-01-01T00:00:30.25

| align="left"|1998-12-31T23:59:59.25

| align="right"|915&nbsp;148&nbsp;799.25

|-

| align="left"|1999-01-01T00:00:30.50

| align="left"|1998-12-31T23:59:59.50

| align="right"|915&nbsp;148&nbsp;799.50

|-

| align="left"|1999-01-01T00:00:30.75

| align="left"|1998-12-31T23:59:59.75

| align="right"|915&nbsp;148&nbsp;799.75

|-

| align="left"|1999-01-01T00:00:31.00

| align="left"|1998-12-31T23:59:60.00

| align="right"|915&nbsp;148&nbsp;799.00

|-

| align="left"|1999-01-01T00:00:31.25

| align="left"|1998-12-31T23:59:60.25

| align="right"|915&nbsp;148&nbsp;799.25

|-

| align="left"|1999-01-01T00:00:31.50

| align="left"|1998-12-31T23:59:60.50

| align="right"|915&nbsp;148&nbsp;799.50

|-

| align="left"|1999-01-01T00:00:31.75

| align="left"|1998-12-31T23:59:60.75

| align="right"|915&nbsp;148&nbsp;799.75

|-

| align="left"|1999-01-01T00:00:32.00

| align="left"|1999-01-01T00:00:00.00

| align="right"|915&nbsp;148&nbsp;800.00

|-

| align="left"|1999-01-01T00:00:32.25

| align="left"|1999-01-01T00:00:00.25

| align="right"|915&nbsp;148&nbsp;800.25

|-

| align="left"|1999-01-01T00:00:32.50

| align="left"|1999-01-01T00:00:00.50

| align="right"|915&nbsp;148&nbsp;800.50

|-

| align="left"|1999-01-01T00:00:32.75

| align="left"|1999-01-01T00:00:00.75

| align="right"|915&nbsp;148&nbsp;800.75

|-

| align="left"|1999-01-01T00:00:33.00

| align="left"|1999-01-01T00:00:01.00

| align="right"|915&nbsp;148&nbsp;801.00

|-

| align="left"|1999-01-01T00:00:33.25

| align="left"|1999-01-01T00:00:01.25

| align="right"|915&nbsp;148&nbsp;801.25

|}

Such behaviour does not conform to POSIX.1, but is very common. As a result, Unix times such as 915&nbsp;148&nbsp;799.50, apparently in the second preceding a leap second, are [[de facto]] ambiguous, as are (both [[de facto]] and [[de jure]]) times such as 915&nbsp;148&nbsp;800.50.

====TAI-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&nbsp;400&nbsp;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 [[bit]]s (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-13T20:45:52Z, and the maximum representable time is 2038-01-19T03:14:07Z. At 2038-01-19T03:14:08Z this representation will [[arithmetic overflow|overflow]]. This milestone is anticipated with a mixture of amusement and dread; see the separate section below.

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 290 billion representable years is truly sufficient depends on the [[ultimate fate of the universe]], but it is certainly adequate for most practical purposes.

There has been 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. 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 -893400000.) The consensus, and universal practice, is for '''time_t''' to be signed.

Unix has no tradition of directly representing non-integer Unix time numbers as binary fractions. Instead, times with sub-second precision are represented using [[composite type|compound data type]]s 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, but more often inconvenient.

===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 uncontroversially 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 is all that is significant to Unix time.

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.

==History==

The earliest versions of Unix time had a 32-bit integer incrementing at a rate of 60&nbsp;[[Hertz|Hz]], which was the rate of the system clock on the hardware of the early Unix systems. The value 60&nbsp;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". It also comments 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.

As of [[as of 2004|2004]], POSIX has new interfaces making several different time scales available to programs, splitting up the many uses to which Unix times have traditionally been put. The future is one where time values are accompanied by explicit labels of the time scale defining their significance. Unix time as described in this article will still be in wide use for decades to come, but is likely to be increasingly treated as a legacy system and superseded by better-defined systems.

==32-bit overflow==

At 03:14:08 UTC on [[January 19]] [[2038]] (+2³¹), a 32-bit signed integer representation of Unix time will [[arithmetic overflow|overflow]]. Systems using a 32-bit signed integer Unix '''time_t''' will therefore be unable to represent that time, or any later, and will likely wrap around to 20:45:52 UTC on [[December 13]] [[1901]], with integer value -2³¹. This is known as the [[year 2038 problem]].

Programs which must handle times beyond the overflow date will need to be changed to use a 64-bit '''time_t''', a [[bignum]] representation of Unix time, or some other means of representing points in time. This is not unlike the [[year 2000 problem]]. Adapting existing programs may be as easy as re-[[compile|compiling]] them with header files that declare '''time_t''' as a 64-bit integer. However this will create problems if and when the time_t value is passed from that program to other code that has not had the definition changed (such as the system's C shared library). Also some other programs make deep assumptions as to the nature of '''time_t''' and the [[source code]] to some software packages may have been lost by then, in which case programmers might have to [[reverse engineering|reverse engineer]] the software to change its date behavior. Some claim that the expiration of 32-bit '''time_t''' may cause more damage than was predicted for the year 2000 problem.

<!--consider reducing this section a bit and putting in a see main article link to [[year 2038 problem]] or merging that article into here-->

==time_t parties==

Unix enthusiasts have a history of holding '''time_t parties''' to celebrate significant values of the Unix time number. These are directly analogous to the [[new year]] celebrations that occur at the change of year in many calendars. As the use of Unix time has spread, so has the practice of celebrating its milestones. Usually it is time values that are round numbers in [[decimal]] that are celebrated, following the Unix convention of viewing time_t values in decimal. Among some groups round [[Binary numeral system|binary]] numbers are also celebrated, such as +2³⁰ which occured at 10:37:04 [[UTC]] on [[January 10]], [[2004]].

The events that these celebrate are typically described as "N seconds since the Unix epoch", but this is inaccurate. As discussed above, due to the handling of [[leap second]]s in Unix time, the number of seconds elapsed since the Unix epoch is slightly greater than the Unix time number, for times later than the epoch.

At 01:46:40 [[UTC]] on [[September 9]], [[2001]], the [[Unix billennium]] (Unix time number 1000000000) was celebrated. There was some concern that the increased length of decimal representation would cause problems for programs that used this representation, but in the end the problems were minor.

At 01:58:31 [[UTC]] on [[March 18]], [[2005]], the Unix time number reached 1111111111. A large celebration was held on [[Internet Relay Chat|IRC]] in the [[Freenode]] channel #1111111111. At its peak the channel held over 200 people and averaged up to 24 messages in a single second.

At 23:31:30 [[UTC]] on [[February 13]], [[2009]], a celebration is expected as the Unix time number reaches 1234567890 seconds.

== See also ==

* [[Unununium Time]]

* [[Year 2000 problem]]

* [[Year 2038 problem]]

==External links==

*[http://cm.bell-labs.com/cm/cs/who/dmr/1stEdman.html Unix Programmer's Manual, first edition]

*[http://esqsoft.com/javascript_examples/date-to-epoch.htm Online tool to convert from Unix time to human-friendly representations, and back]

*[http://soft.zoneo.net/Unixtime/index.php Unixtime online: Convert unix time to plain english, and vice-versa!]

[[Category:Unix]]

[[Category:Time scales]]

[[de:Unixzeit]]

[[pl:EPOCH]]

[[ru:&#1042;&#1088;&#1077;&#1084;&#1103; (&#1070;&#1085;&#1080;&#1082;&#1089;)]]

[[fi:UNIX-aika]]

[[ka:იუნიქსის_დრო]]