View source for Unix time

{{short description|Date and time representation system widely used in computing}}
{{Redirect|January 1, 1970|the date|January 1, 1970 (date)}}
{{Redirect|Epoch time|other epochs|Epoch (computing)|the newspaper|The Epoch Times{{!}}''The Epoch Times''}}
{{Use dmy dates|date=May 2023}}

[[File:1000000000seconds.jpg|right|thumb|Unix time passed {{val|1000000000}} seconds on 2001-09-09T01:46:40Z.<ref name="wired-farhad">{{Cite magazine |last=Farhad |first=Manjoo |date=8 September 2001 |title=Unix Tick Tocks to a Billion |language=en-US |magazine=Wired |url=https://www.wired.com/2001/09/unix-tick-tocks-to-a-billion/ |access-date=16 October 2022 |issn=1059-1028 |archive-date=11 September 2022 |archive-url=https://web.archive.org/web/20220911005342/https://www.wired.com/2001/09/unix-tick-tocks-to-a-billion/ |url-status=live }}</ref> It was celebrated in Copenhagen, Denmark, at a party held by the [[Danish UNIX User Group]] at 03:46:40 local time.]]

'''Unix time'''{{efn|Unix time is also known as "Epoch time", "[[POSIX]] time",<ref>{{Cite web |url=https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html |title=The Open Group Base Specifications Issue 7, Rationale: Base Definitions, section A.4 General Concepts |publisher=[[The Open Group]] |access-date=9 September 2019 |archive-date=15 November 2017 |archive-url=https://web.archive.org/web/20171115154605/http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html |url-status=live }}</ref> "seconds since the Epoch",<ref name="single-unix-spec-4.16">{{cite web|url=http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16|title=The Open Group Base Specifications Issue 7, section 4.16 Seconds Since the Epoch|publisher=[[The Open Group]]|access-date=22 January 2017|archive-date=22 December 2017|archive-url=https://web.archive.org/web/20171222113543/http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16|url-status=live}}</ref> "Unix timestamp" or "UNIX Epoch time".<ref>{{Cite book|title=Beginning Linux Programming|last1=Matthew|first1=Neil|last2=Stones|first2=Richard|publisher=Wiley|year=2008|isbn=978-0-470-14762-7|location=Indianapolis, Indiana, US|pages=148|chapter=The Linux Environment}}</ref>}} is a date and time representation widely used in [[computing]]. It measures time by the number of non-[[leap second]]s that have elapsed since 00:00:00 [[Coordinated Universal Time|UTC]] on 1&nbsp;January 1970, the Unix [[Epoch (computing)|epoch]]. For example, at midnight on 1 January 2010, Unix time was 1262304000.

Unix time originated as the [[system time]] of [[Unix]] operating systems. It has come to be widely used in other computer [[operating systems]], [[file systems]], [[programming languages]], and [[databases]]. In modern computing, values are sometimes stored with higher [[Data granularity|granularity]], such as [[microsecond]]s or [[nanosecond]]s.

== Definition ==
Unix time is currently defined as the number of non-leap seconds which have passed since 00:00:00{{nbsp}}UTC on Thursday, 1&nbsp;January 1970, which is referred to as the ''Unix [[epoch (computing)|epoch]]''.<ref name="single-unix-spec-4.16" /> Unix time is typically encoded as a [[signed integer]].

The Unix time {{val|0}} is exactly midnight UTC on 1&nbsp;January 1970, with Unix time incrementing by 1 for every non-leap second after this. For example, 00:00:00{{nbsp}}UTC on 1&nbsp;January 1971 is represented in Unix time as {{val|31536000}}. Negative values, on systems that support them, indicate times before the Unix epoch, with the value decreasing by 1 for every non-leap second before the epoch. For example, 00:00:00{{nbsp}}UTC on 1&nbsp;January 1969 is represented in Unix time as {{val|-31536000}}. Every day in Unix time consists of exactly {{val|86400}} seconds.

Unix time is sometimes referred to as ''Epoch time''. This can be misleading since Unix time is not the only time system based on an epoch and the Unix epoch is not the only epoch used by other time systems.<ref>{{cite web |url=https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ns-minwinbase-filetime |title=FILETIME structure (minwinbase.h) |website=[[Microsoft Docs]]|date=2 April 2021 }}</ref>

=== Leap seconds ===
Unix time differs from both [[Coordinated Universal Time]] (UTC) and [[International Atomic Time]] (TAI) in its handling of [[leap second]]s. UTC includes leap seconds that adjust for the discrepancy between precise time, as measured by [[atomic clocks]], and [[solar time]], relating to the position of the earth in relation to the sun. [[International Atomic Time]] (TAI), in which every day is precisely {{val|86400}} seconds long, ignores solar time and gradually loses [[synchronization]] with the Earth's rotation at a rate of roughly one second per year. In Unix time, every day contains exactly {{val|86400}} seconds. Each leap second uses the [[timestamp]] of a second that immediately precedes or follows it.<ref name="single-unix-spec-4.16"/>

On a normal UTC day, which has a duration of {{val|86400}} seconds, 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 as follows:

{| class="wikitable" style="text-align: center;"
|+ Unix time across midnight into 17 September 2004 (without leap seconds)
|-
! TAI (17 September 2004)
! UTC (16 to 17 September 2004)
! Unix time
|-
| 2004-09-17T00:00:30.75
| 2004-09-16T23:59:58.75
| style="text-align: right;" | {{val|1095379198.75}}
|-
| 2004-09-17T00:00:31.00
| 2004-09-16T23:59:59.00
| style="text-align: right;" | {{val|1095379199.00}}
|-
| 2004-09-17T00:00:31.25
| 2004-09-16T23:59:59.25
| style="text-align: right;" | {{val|1095379199.25}}
|-
| 2004-09-17T00:00:31.50
| 2004-09-16T23:59:59.50
| style="text-align: right;" | {{val|1095379199.50}}
|-
! 2004-09-17T00:00:31.75
! 2004-09-16T23:59:59.75
! style="text-align: right;" | {{val|1095379199.75}}
|-
! 2004-09-17T00:00:32.00
! 2004-09-17T00:00:00.00
! style="text-align: right;" | {{val|1095379200.00}}
|-
| 2004-09-17T00:00:32.25
| 2004-09-17T00:00:00.25
| style="text-align: right;" | {{val|1095379200.25}}
|-
| 2004-09-17T00:00:32.50
| 2004-09-17T00:00:00.50
| style="text-align: right;" | {{val|1095379200.50}}
|-
| 2004-09-17T00:00:32.75
| 2004-09-17T00:00:00.75
| style="text-align: right;" | {{val|1095379200.75}}
|-
| 2004-09-17T00:00:33.00
| 2004-09-17T00:00:01.00
| style="text-align: right;" | {{val|1095379201.00}}
|-
| 2004-09-17T00:00:33.25
| 2004-09-17T00:00:01.25
| style="text-align: right;" | {{val|1095379201.25}}
|}

When a [[leap second]] occurs, the UTC day is not exactly {{val|86400}} seconds long and the Unix time number (which always increases by exactly {{val|86400}} each day) experiences a [[discontinuity (mathematics)|discontinuity]]. Leap seconds may be positive or negative. No negative leap second has ever been declared, but if one were to be, then at the end of a day with a negative leap second, the Unix time number would jump up by 1 to the start of the next day. During a positive leap second at the end of a day, which occurs about every year and a half on average, the Unix time number increases continuously into the next day during the leap second and then at the end of the leap second jumps back by 1 (returning to the start of the next day). For example, this is what happened on strictly conforming [[POSIX.1]] systems at the end of 1998:

{| class="wikitable" id="leapsecondinserted" style="text-align: center;"
|+ Unix time across midnight into 1 January 1999 (positive leap second)
|-
! 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
| style="text-align: right;" | {{val|915148798.75}}
|-
| 1999-01-01T00:00:30.00
| 1998-12-31T23:59:59.00
| style="text-align: right;" | {{val|915148799.00}}
|-
| 1999-01-01T00:00:30.25
| 1998-12-31T23:59:59.25
| style="text-align: right;" | {{val|915148799.25}}
|-
| 1999-01-01T00:00:30.50
| 1998-12-31T23:59:59.50
| style="text-align: right;" | {{val|915148799.50}}
|-
| 1999-01-01T00:00:30.75
| 1998-12-31T23:59:59.75
| style="text-align: right;" | {{val|915148799.75}}
|-
| 1999-01-01T00:00:31.00
! 1998-12-31T23:59:60.00
| style="text-align: right;" | {{val|915148800.00}}
|-
| 1999-01-01T00:00:31.25
! 1998-12-31T23:59:60.25
| style="text-align: right;" | {{val|915148800.25}}
|-
| 1999-01-01T00:00:31.50
! 1998-12-31T23:59:60.50
| style="text-align: right;" | {{val|915148800.50}}
|-
! 1999-01-01T00:00:31.75
! 1998-12-31T23:59:60.75
! style="text-align: right;" | {{val|915148800.75}}
|-
! 1999-01-01T00:00:32.00
! 1999-01-01T00:00:00.00
! style="text-align: right;" | {{val|915148800.00}}
|-
| 1999-01-01T00:00:32.25
| 1999-01-01T00:00:00.25
| style="text-align: right;" | {{val|915148800.25}}
|-
| 1999-01-01T00:00:32.50
| 1999-01-01T00:00:00.50
| style="text-align: right;" | {{val|915148800.50}}
|-
| 1999-01-01T00:00:32.75
| 1999-01-01T00:00:00.75
| style="text-align: right;" | {{val|915148800.75}}
|-
| 1999-01-01T00:00:33.00
| 1999-01-01T00:00:01.00
| style="text-align: right;" | {{val|915148801.00}}
|-
| 1999-01-01T00:00:33.25
| 1999-01-01T00:00:01.25
| style="text-align: right;" | {{val|915148801.25}}
|}

Unix time numbers are repeated in the second immediately following a positive leap second. The Unix time number {{val|1483228800}} is thus ambiguous: it can refer either to start of the leap second (2016-12-31 23:59:60) or the end of it, one second later (2017-01-01 00:00:00). In the theoretical case when a negative leap second occurs, no ambiguity is caused, but instead there is a range of Unix time numbers that do not refer to any point in UTC 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 from this problem.

A Unix time number is easily converted back into a UTC time by taking the quotient and modulus of the Unix time number, modulo {{val|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. 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.

==== Non-synchronous Network Time Protocol-based variant ====
Commonly a [[David L. Mills|Mills]]-style Unix clock is implemented with leap second handling not synchronous with the change of the Unix time number. The time number initially decreases where a leap should have occurred, and then it leaps to the correct time 1 second after the leap. This makes implementation easier, and is described by Mills' paper.<ref name="eeci_TheN">{{Cite web | title = The NTP Timescale and Leap Seconds | last = Mills | first = David L. | work = eecis.udel.edu | date = 12 May 2012 | access-date = 21 August 2017 | url = https://www.eecis.udel.edu/~mills/leap.html | archive-date = 15 May 2012 | archive-url = https://web.archive.org/web/20120515005611/http://www.eecis.udel.edu/~mills/leap.html | url-status = live }}</ref> This is what happens across a positive leap second:

{| class="wikitable" style="text-align: center;"
|+ Non-synchronous Mills-style Unix clock<br>across midnight into 1 January 1999 (positive leap second)
|-
! TAI (1 January 1999)
! UTC (31 December 1998 to 1 January 1999)
! State
! Unix clock
|-
| 1999-01-01T00:00:29.75
| 1998-12-31T23:59:58.75
| TIME_INS
| style="text-align: right;" | {{val|915148798.75}}
|-
| 1999-01-01T00:00:30.00
| 1998-12-31T23:59:59.00
| TIME_INS
| style="text-align: right;" | {{val|915148799.00}}
|-
| 1999-01-01T00:00:30.25
| 1998-12-31T23:59:59.25
| TIME_INS
| style="text-align: right;" | {{val|915148799.25}}
|-
| 1999-01-01T00:00:30.50
| 1998-12-31T23:59:59.50
| TIME_INS
| style="text-align: right;" | {{val|915148799.50}}
|-
| 1999-01-01T00:00:30.75
| 1998-12-31T23:59:59.75
| TIME_INS
| style="text-align: right;" | {{val|915148799.75}}
|-
! 1999-01-01T00:00:31.00
! 1998-12-31T23:59:60.00
! TIME_INS
! style="text-align: right;" | {{val|915148800.00}}
|-
! 1999-01-01T00:00:31.25
! 1998-12-31T23:59:60.25
! TIME_OOP
! style="text-align: right;" | {{val|915148799.25}}
|-
| 1999-01-01T00:00:31.50
| 1998-12-31T23:59:60.50
| TIME_OOP
| style="text-align: right;" | {{val|915148799.50}}
|-
! 1999-01-01T00:00:31.75
! 1998-12-31T23:59:60.75
! TIME_OOP
! style="text-align: right;" | {{val|915148799.75}}
|-
! 1999-01-01T00:00:32.00
! 1999-01-01T00:00:00.00
! TIME_OOP
! style="text-align: right;" | {{val|915148800.00}}
|-
| 1999-01-01T00:00:32.25
| 1999-01-01T00:00:00.25
| TIME_WAIT
| style="text-align: right;" | {{val|915148800.25}}
|-
| 1999-01-01T00:00:32.50
| 1999-01-01T00:00:00.50
| TIME_WAIT
| style="text-align: right;" | {{val|915148800.50}}
|-
| 1999-01-01T00:00:32.75
| 1999-01-01T00:00:00.75
| TIME_WAIT
| style="text-align: right;" | {{val|915148800.75}}
|-
| 1999-01-01T00:00:33.00
| 1999-01-01T00:00:01.00
| TIME_WAIT
| style="text-align: right;" | {{val|915148801.00}}
|-
| 1999-01-01T00:00:33.25
| 1999-01-01T00:00:01.25
| TIME_WAIT
| style="text-align: right;" | {{val|915148801.25}}
|}

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.

==== Variant that counts leap seconds ====
Another, much rarer, non-conforming variant of Unix time keeping involves incrementing the value for all seconds, including leap seconds;<ref>{{cite web|url=https://www.iana.org/time-zones/repository/tz-link.html#precision|work=Sources for time zone and daylight saving time data|title=Precision timekeeping|quote=The tz code and data support leap seconds via an optional "right" configuration where a computer's internal time_t integer clock counts every TAI second, as opposed to the default "posix" configuration where the internal clock ignores leap seconds. The two configurations agree for timestamps starting with 1972-01-01 00:00:00 UTC (time_t 63 072 000) and diverge for timestamps starting with time_t 78 796 800, which corresponds to the first leap second 1972-06-30 23:59:60 UTC in the "right" configuration, and to 1972-07-01 00:00:00 UTC in the "posix" configuration.|access-date=30 May 2022|archive-date=16 October 2017|archive-url=https://web.archive.org/web/20171016230241/http://www.iana.org/time-zones/repository/tz-link.html#precision|url-status=live}}</ref> some Linux systems are configured this way.<ref name="ntp-time-scales">{{cite web|title=Time Scales|url=https://support.ntp.org/bin/view/Support/TimeScales|work=Network Time Protocol Wiki|date=24 July 2019|access-date=12 January 2020|archive-date=12 January 2020|archive-url=https://web.archive.org/web/20200112103701/https://support.ntp.org/bin/view/Support/TimeScales|url-status=live}}</ref> Time kept in this fashion is sometimes referred to as "TAI" (although timestamps can be converted to UTC if the value corresponds to a time when the difference between TAI and UTC is known), as opposed to "UTC" (although not all UTC time values have a unique reference in systems that do not count leap seconds).<ref name="ntp-time-scales" />

Because TAI has no leap seconds, and every TAI day is exactly 86400 seconds long, this encoding is actually a pure linear count of seconds elapsed since 1970-01-01T00:00:10{{nbsp}}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 to correctly convert between UTC and the pseudo-Unix-time representation. This resembles the manner in which time zone tables must be consulted to convert to and from [[civil time]]; the [[IANA time zone database]] includes leap second information, and the sample code available from the same source uses that information to convert between TAI-based timestamps and local time. Conversion also runs into definitional problems prior to the 1972 commencement of the current form of UTC (see section [[#UTC basis|UTC basis]] below).

This system, despite its superficial resemblance, is not Unix time. It encodes times with values that differ by several seconds from the POSIX time values. A version of this system, in which the epoch was 1970-01-01T00:00:00{{nbsp}}TAI rather than 1970-01-01T00:00:10{{nbsp}}TAI, was proposed for inclusion in ISO C's [[C date and time functions|{{code|time.h}}]], but only the UTC part was accepted in 2011.<ref>{{cite web |author=Markus Kuhn |title=Modernized API for ISO C |url=https://www.cl.cam.ac.uk/~mgk25/time/c/ |website=www.cl.cam.ac.uk |access-date=31 August 2020 |archive-date=26 September 2020 |archive-url=https://web.archive.org/web/20200926224028/https://www.cl.cam.ac.uk/~mgk25/time/c/ |url-status=live }}</ref> A {{code|tai_clock}} does, however, exist in C++20.

=== 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 problems. However, certain binary representations of Unix times are particularly significant.

The Unix <!-- time_t meaning time type is a C type name. DO NOT REPLACE «time_t» WITH «time t»!!! --><code>[[time_t]]</code><!-- DO NOT REPLACE «time_t» WITH «time t»!!! --> data type that represents a point in time is, on many platforms, a [[Integer (computer science)|signed integer]], traditionally of 32{{nbsp}}[[bit]]s (but [[#Range of representable times|see below]]), directly encoding the Unix time number as described in the preceding section. A signed 32-bit value covers about 68 years before and after the 1970-01-01 epoch. The minimum representable date is Friday 1901-12-13, and the maximum representable date is Tuesday 2038-01-19. One second after 2038-01-19T03:14:07Z this representation will [[arithmetic overflow|overflow]] in what is known as the [[year 2038 problem]].

[[UUID]]v7 encodes the Unix epoch timestamp (in milliseconds) in an unsigned 48-bit field. This representation is valid until the year 10889 AD.<ref>
{{IETF RFC|9562}}
</ref>

In some newer operating systems, <code>time_t</code> has been widened to 64 bits. This expands the times representable to about {{tooltip|1={{round|2^63/365.2422/24/3600/10^9|1}} billion years|2=More precisely, 292277264695 years}}<!-- note:including {{round}} inside {{tooltip}} doesn't work when the resulting number results has an exponent --> in both directions, which is over twenty times the present [[age of the universe]].

There was originally some controversy over whether the Unix <code>time_t</code> 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 the epoch. The consensus is for <code>time_t</code> to be signed, and this is the usual practice. The software development platform for version 6 of the [[QNX]] operating system has an unsigned 32-bit <code>time_t</code>, though older releases used a signed type.

The [[POSIX]] and [[Open Group]] Unix specifications include the [[C standard library]], which includes the time types and functions defined in the [[time.h|<code>&lt;time.h&gt;</code>]] header file. The ISO C standard states that <code>time_t</code> must be an arithmetic type, but does not mandate any specific type or encoding for it. POSIX requires <code>time_t</code> to be an integer type, but does not mandate that it be signed or unsigned.

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 data type]]s that consist of two integers, the first being a <code>time_t</code> (the integral part of the Unix time), and the second being the fractional part of the time number in millionths (in <code>struct timeval</code>) or billionths (in <code>struct timespec</code>).<ref>{{cite web |title=timespec |url=https://netbsd.gw.com/cgi-bin/man-cgi?timespec |website=NetBSD Manual Pages |access-date=5 July 2019 |date=12 April 2011 |archive-date=10 August 2019 |archive-url=https://web.archive.org/web/20190810060329/https://netbsd.gw.com/cgi-bin/man-cgi?timespec |url-status=live }}</ref><ref>{{cite web |title=time.h(0P) |url=http://man7.org/linux/man-pages/man0/time.h.0p.html |website=Linux manual page |access-date=5 July 2019 |archive-date=27 June 2019 |archive-url=https://web.archive.org/web/20190627152007/http://man7.org/linux/man-pages/man0/time.h.0p.html |url-status=live }}</ref> These structures provide a [[decimal]]-based [[Fixed-point arithmetic|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 starting from 1&nbsp;January 1972. Prior to that, since 1&nbsp;January 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 to continuously approximate the Earth's rotation. Prior to 1961 there was no UTC, and prior to 1958 there was no widespread [[atomic clock|atomic timekeeping]]; in these eras, some approximation of [[GMT]] (based directly on the Earth's rotation) was used instead of an atomic timescale.{{Citation needed|date=May 2012}}

The precise definition of Unix time as an encoding of UTC is only uncontroversial when applied to the present form of UTC. The Unix epoch predating the start of this form of UTC does not affect its use in this era: the number of days from 1&nbsp;January 1970 (the Unix epoch) to 1&nbsp;January 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 {{val|+63072000}} (i.e., prior to 1 January 1972) is not precisely defined. The basis of such Unix times is best understood to be an unspecified approximation of UTC. 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 use.

{{As of|2009}}, the possibility of ending the use of leap seconds in civil time is being considered.<ref>{{Cite book
 | last1=McCarthy   | first1=D. D.
 | last2=Seidelmann | first2=P. K.
 | author-link1=Dennis McCarthy (scientist)
 | date=2009
 | title=TIME—From Earth Rotation to Atomic Physics
 | page=232
 | publisher=Wiley–VCH Verlag GmbH & Co. KGaA
 | location=Weinheim
 | isbn=978-3-527-40780-4
}}</ref> A likely means to execute this change is to define a new time scale, called ''International Time''{{Citation needed|date=February 2023}}, 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 ==
{{More citations needed section|date=September 2019}}
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. Timestamps stored this way could only represent a range of a little over two and a quarter years. The epoch being counted from was changed with Unix releases to prevent overflow, with midnight on 1&nbsp;January 1971 and 1&nbsp;January 1972 both being used as epochs during Unix's early development. Early definitions of Unix time also lacked timezones.<ref>{{cite book|title=Unix Programmer's Manual|edition=1st|url=https://www.bell-labs.com/usr/dmr/www/pdfs/man22.pdf|quote="''time'' returns the time since 00:00:00, Jan. 1, 1971, measured in sixtieths of a second."|date=3 November 1971|access-date=28 March 2012|archive-date=5 March 2022|archive-url=https://web.archive.org/web/20220305094724/https://www.bell-labs.com/usr/dmr/www/pdfs/man22.pdf|url-status=live}}</ref><ref>{{cite book|title=Unix Programmer's Manual|edition=3rd|url=http://bitsavers.org/pdf/att/unix/3rd_Edition/UNIX_Programmers_Manual_Third_Edition_Feb73.pdf|quote="''time'' returns the time since 00:00:00, Jan. 1, 1972, measured in sixtieths of a second...The time is stored in 32 bits. This guarantees a crisis every 2.26 years."|date=15 March 1972|access-date=11 February 2023|archive-date=12 February 2023|archive-url=https://web.archive.org/web/20230212065854/http://bitsavers.org/pdf/att/unix/3rd_Edition/UNIX_Programmers_Manual_Third_Edition_Feb73.pdf|url-status=live}}</ref>

The current epoch of 1&nbsp;January 1970 00:00:00 UTC was selected arbitrarily by Unix engineers because it was considered a convenient date to work with. The precision was changed to count in seconds in order to avoid short-term overflow.{{r|wired-farhad}}

When [[POSIX#POSIX.1|POSIX.1]] was written, the question arose of how to precisely define <code>time_t</code> in the face of leap seconds. The POSIX committee considered whether Unix time should remain, as intended, a linear count of seconds since the epoch, at the expense of complexity in conversions with civil time or a 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,<ref>{{Cite web |title=Posix Has Become Outdated (2016) [pdf] {{!}} Hacker News |url=https://news.ycombinator.com/item?id=13621623 |archive-url=https://web.archive.org/web/20250318023606/https://news.ycombinator.com/item?id=13621623 |archive-date=18 March 2025 |access-date=2025-07-23 |website=news.ycombinator.com |language=en |url-status=live }}</ref> and firmly defined the Unix time in a simple manner in terms of the elements of UTC time. This definition was so simple that it did not 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. 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]], to execute steps in the Unix time number whenever leap seconds occur.{{Citation needed|date=May 2020}}

== Usage ==
Unix time is widely adopted in computing beyond its original application as the system time for [[Unix]]. Unix time is available in almost all system programming [[API]]s, including those provided by both Unix-based and non-Unix [[operating systems]]. Almost all modern [[programming languages]] provide APIs for working with Unix time or converting them to another data structure. Unix time is also used as a mechanism for storing timestamps in a number of [[file systems]], [[file formats]], and [[databases]].

The [[C standard library]] uses Unix time for all date and time functions, and Unix time is sometimes referred to as time_t, the name of the [[data type]] used for timestamps in [[C (programming language)|C]] and [[C++]]. C's Unix time functions are defined as the system time API in the [[POSIX]] specification.<ref>{{cite web |title=The Open Group Technical Standard Base Specifications Issue 7 (2018 edition) |url=https://pubs.opengroup.org/onlinepubs/9699919799/functions/time.html |publisher=IEEE and The Open Group |access-date=1 May 2023 |archive-date=1 May 2023 |archive-url=https://web.archive.org/web/20230501172931/https://pubs.opengroup.org/onlinepubs/9699919799/functions/time.html |url-status=live }}</ref> <!-- TODO reword --> The C standard library is used extensively in all modern desktop operating systems, including [[Microsoft Windows]] and [[Unix-like]] systems such as [[macOS]] and [[Linux]], where it is a standard programming interface.<ref name="windows-unix-time">{{cite web |title=time, _time32, _time64 |url=https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/time-time32-time64?view=msvc-170 |website=learn.microsoft.net | date=13 February 2023 |publisher=Microsoft Corporation |access-date=1 May 2023 |archive-date=1 May 2023 |archive-url=https://web.archive.org/web/20230501184037/https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/time-time32-time64?view=msvc-170 |url-status=live }}</ref><ref>{{cite web |title=The GNU C Library (glibc) |url=https://www.gnu.org/software/libc/ |website=The GNU Operating Sisyem |publisher=Free Software Foundation |access-date=1 May 2023 |quote=The GNU C Library project provides the core libraries for the GNU system and GNU/Linux systems, as well as many other systems that use Linux as the kernel. |archive-date=22 April 2016 |archive-url=https://web.archive.org/web/20160422061403/http://www.gnu.org/software/libc/ |url-status=live }}</ref><ref>{{cite web |title=Mac OS X Manual Page for localtime(3) |url=https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/localtime.3.html |website=Apple Documentation Archive |publisher=Apple Inc. |access-date=1 May 2023 |archive-date=22 July 2022 |archive-url=https://web.archive.org/web/20220722085416/https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/localtime.3.html |url-status=live }}</ref>

[[iOS]] provides a Swift API which defaults to using an epoch of 1&nbsp;January 2001 but can also be used with Unix timestamps.<ref>{{cite web |title=NSDate |url=https://developer.apple.com/documentation/foundation/nsdate |website=Apple Developer Documentation |publisher=Apple Inc. |access-date=1 May 2023 |archive-date=1 May 2023 |archive-url=https://web.archive.org/web/20230501172929/https://developer.apple.com/documentation/foundation/nsdate |url-status=live }}</ref> [[Android (operating system)|Android]] uses Unix time alongside a timezone for its system time API.<ref>{{cite web |title=Time Overview |url=https://source.android.com/docs/core/connect/time |website=Android Open Source Project |publisher=Google LLC |access-date=1 May 2023 |archive-date=1 May 2023 |archive-url=https://web.archive.org/web/20230501172931/https://source.android.com/docs/core/connect/time |url-status=live }}</ref>

Windows does not use Unix time for storing time internally but does use it in system APIs, which are provided in C++ and implement the C standard library specification.<ref name="windows-unix-time" /> Unix time is used in the [[PE format]] for Windows executables.<ref>{{cite web |title=PE Format - Win32 apps |url=https://learn.microsoft.com/en-us/windows/win32/debug/pe-format |website=learn.microsoft.com |date=24 March 2023 |publisher=Microsoft Corporation |access-date=1 May 2023 |language=en-us |archive-date=29 April 2023 |archive-url=https://web.archive.org/web/20230429214701/https://learn.microsoft.com/en-us/windows/win32/debug/pe-format |url-status=live }}</ref>

Unix time is typically available in major programming languages and is widely used in desktop, mobile, and web application programming. [[Java (programming language)|Java]] provides an Instant object which holds a Unix timestamp in both seconds and nanoseconds.<ref>{{cite web |title=Instant (Java Platform SE 8 ) |url=https://docs.oracle.com/javase/8/docs/api/java/time/Instant.html |website=docs.oracle.com |publisher=Oracle |access-date=1 May 2023 |archive-date=25 November 2016 |archive-url=https://web.archive.org/web/20161125045518/http://docs.oracle.com/javase/8/docs/api/java/time/Instant.html |url-status=live }}</ref> [[Python (programming language)|Python]] provides a time library which uses Unix time.<ref>{{citation | url=https://docs.python.org/3/library/time.html | title=time — Time access and conversions | work=Python documentation | accessdate=25 July 2022 | archive-date=22 July 2022 | archive-url=https://web.archive.org/web/20220722022415/https://docs.python.org/3/library/time.html | url-status=live }}</ref> [[JavaScript]] provides a Date library which provides and stores timestamps in milliseconds since the Unix epoch and is implemented in all modern desktop and mobile [[web browsers]] as well as in JavaScript server environments like [[Node.js]].<ref>{{cite web |title=Date - JavaScript {{!}} MDN |url=https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date |website=developer.mozilla.org |publisher=Mozilla |access-date=1 May 2023 |archive-date=21 July 2021 |archive-url=https://web.archive.org/web/20210721082721/https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date |url-status=live }}</ref>

[[Free Pascal]] implements UNIX time with the GetTickCount (deprecated unsigned 32 bit) and GetTickCount64 (Unsigned 64 bit) functions to a resolution of 1ms on [[Unix-like]] platforms.

Filesystems designed for use with Unix-based operating systems tend to use Unix time. [[APFS]], the file system used by default across all Apple devices, and [[ext4]], which is widely used on Linux and Android devices, both use Unix time in nanoseconds for file timestamps.<ref name="apfs">{{citation|url=https://developer.apple.com/support/downloads/Apple-File-System-Reference.pdf|title=Apple File System Reference|page=57|access-date=19 October 2022|quote=This timestamp is represented as the number of nanoseconds since January 1, 1970 at 0:00 UTC, disregarding leap seconds|archive-date=5 November 2022|archive-url=https://web.archive.org/web/20221105082749/https://developer.apple.com/support/downloads/Apple-File-System-Reference.pdf|url-status=live}}</ref><ref>{{cite web |title=Data Structures and Algorithms |url=https://www.kernel.org/doc/html/v4.19/filesystems/ext4/ondisk/index.html#inode-timestamps |website=The Linux Kernel documentation |publisher=Linux Kernel Organization, Inc. |access-date=1 May 2023 |archive-date=1 May 2023 |archive-url=https://web.archive.org/web/20230501193249/https://www.kernel.org/doc/html/v4.19/filesystems/ext4/ondisk/index.html#inode-timestamps |url-status=live }}</ref> Several [[archive file format]]s can store timestamps in Unix time, including [[RAR (file format)|RAR]] and [[tar (computing)|tar]].<ref>{{cite web |title=RAR 5.0 archive format |url=https://www.rarlab.com/technote.htm |website=www.rarlab.com |publisher=win.rar GmbH |access-date=1 May 2023 |quote=Time is stored in Unix time_t format if this flags [sic] is set and in Windows FILETIME format otherwise |archive-date=1 May 2023 |archive-url=https://web.archive.org/web/20230501201914/https://www.rarlab.com/technote.htm |url-status=live }}</ref><ref>{{cite web |title=Tape Archive (tar) File Format Family |url=https://www.loc.gov/preservation/digital/formats/fdd/fdd000531.shtml |website=www.loc.gov |publisher=Library of Congress |access-date=1 May 2023 |date=7 January 2021 |archive-date=1 May 2023 |archive-url=https://web.archive.org/web/20230501201909/https://www.loc.gov/preservation/digital/formats/fdd/fdd000531.shtml |url-status=live }}</ref> Unix time is also commonly used to store timestamps in databases, including in [[MySQL]] and [[PostgreSQL]].<ref name="mysql">{{citation|url=https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html|title=Date and Time Functions|work=MySQL 8.0 Reference Manual|accessdate=19 October 2022|archive-date=19 October 2022|archive-url=https://web.archive.org/web/20221019165011/https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html|url-status=live}}</ref><ref>{{cite web |title=8.5. Date/Time Types |url=https://www.postgresql.org/docs/current/datatype-datetime.html |website=PostgreSQL Documentation |publisher=The PostgreSQL Global Development Group |access-date=1 May 2023 |language=en |date=9 February 2023 |archive-date=1 May 2023 |archive-url=https://web.archive.org/web/20230501123216/https://www.postgresql.org/docs/current/datatype-datetime.html |url-status=live }}</ref>

== Limitations ==
Unix time was designed to encode calendar dates and times in a compact manner intended for use by computers internally. It is not intended to be easily read by humans or to store timezone-dependent values. It is also limited by default to representing time in seconds, making it unsuited for use when a more precise measurement of time is needed, such as when measuring the execution time of programs.<ref name="adv-unix">{{cite book |last1=Rochkind |first1=Mark |title=Advanced UNIX Programing |date=2004 |publisher=Addison-Wesley |isbn=978-0-13-141154-8 |pages=56–63 |edition=2nd}}</ref>

=== Range of representable times ===
{{see also|Year 2038 problem}}

[[File:Year 2038 problem.gif|thumb|upright=1.8|An animated visual of the [[Year 2038 problem|32-bit Unix time overflow which will occur in 2038]]]]

Unix time by design does not require a specific size for the storage, but most common implementations of Unix time use a [[signed integer]] with the same size as the [[Word (computer architecture)|word size]] of the underlying hardware. As the majority of modern computers are [[32-bit]] or [[64-bit]], and a large number of programs are still written in 32-bit compatibility mode, this means that many programs using Unix time are using signed 32-bit integer fields. The maximum value of a signed 32-bit integer is {{nowrap|2{{sup|31}} &minus; 1}}, and the minimum value is {{nowrap|&minus;2{{sup|31}}}}, making it impossible to represent dates before 13 December 1901 (at 20:45:52 UTC) or after 19 January 2038 (at 03:14:07 UTC). The early cutoff can have an impact on databases that are storing historical information; in some databases where 32-bit Unix time is used for timestamps, it may be necessary to store time in a different form of field, such as a string, to represent dates before 1901. The late cutoff is known as the [[Year 2038 problem]] and has the potential to cause issues as the date approaches, as dates beyond the 2038 cutoff would wrap back around to the start of the representable range in 1901.{{r|adv-unix|p=60}}<ref>{{Cite web |date=2000-04-01 |title=What is the Year 2038 problem? |url=https://computer.howstuffworks.com/question75.htm |access-date=2025-07-23 |website=HowStuffWorks |language=en-us}}</ref>

Date range cutoffs are not an issue with 64-bit representations of Unix time, as the effective range of dates representable with Unix time stored in a signed 64-bit integer is over 584 billion years, or 292 billion years in either direction of the 1970 epoch.{{r|adv-unix|p=60-61}}<ref>{{cite web |last1=Saxena |first1=Ashutosh |last2=Rawat |first2=Sanjay |title=IDRBT Working Paper No. 9 |url=http://www.idrbt.ac.in/publications/workingpapers/Working%20Paper%20No.%209.pdf |archive-url=https://web.archive.org/web/20120513133703/http://www.idrbt.ac.in/publications/workingpapers/Working%20Paper%20No.%209.pdf |archive-date=13 May 2012 |url-status=dead}}</ref>

== Alternatives ==
Unix time is not the only standard for time that counts away from an epoch. The [[C-Sharp (programming language)|C# programming language]]'s <code>DateTime</code> structure, the <code>FILETIME</code> type in [[Microsoft Windows|Windows]], and [[Cosmos DB|Azure Cosmos DB]]'s <code>GetCurrentTicks</code> function store time as a count of 100-nanosecond intervals that have elapsed since 0:00&nbsp;[[GMT]] on 1&nbsp;January [[AD 1|1&nbsp;AD]],<ref>{{Cite web |title=DateTime Struct (System) |url=https://learn.microsoft.com/en-us/dotnet/api/system.datetime?view=net-9.0 |access-date=2025-01-14 |website=learn.microsoft.com |language=en-us}}</ref> 1&nbsp;January 1601,<ref>{{cite web |title=FILETIME (minwinbase.h) - Win32 apps |url=https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ns-minwinbase-filetime |website=Microsoft Learn |date=2 April 2021 |publisher=Microsoft |access-date=9 March 2023 |archive-date=10 March 2023 |archive-url=https://web.archive.org/web/20230310065235/https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ns-minwinbase-filetime |url-status=live }}</ref> and 1&nbsp;January 1970,<ref>{{Cite web |title=GetCurrentTicks - Azure Cosmos DB for NoSQL |url=http://learn.microsoft.com/en-us/azure/cosmos-db/nosql/query/getcurrentticks |access-date=2025-08-31 |website=learn.microsoft.com |language=en-us}}</ref> which will not overflow until the years 29228,<ref name="csdates">{{Cite web|title=Critical and Significant Dates|url=http://people.cs.nycu.edu.tw/~tsaiwn/sisc/runtime_error_200_div_by_0/www.merlyn.demon.co.uk/critdate.htm|access-date=2024-02-12 |website=people.cs.nycu.edu.tw |language=en}}</ref><ref>{{Cite web |title=Working around accounts that expire with AAD Connect: REDUX |url=http://www.undocumented-features.com/2023/04/26/working-around-accounts-that-expire-with-aad-connect-redux/ |website=www.undocumented-features.com |language=en}}</ref> 30828,<ref name="csdates" /><ref>{{Cite news |last=Thulin|first=Anders|title=Interpretation of NTFS Timestamps |work=Forensic Focus |date=6 April 2013 |url=http://articles.forensicfocus.com/2013/04/06/interpretation-of-ntfs-timestamps/|access-date=23 July 2019}}</ref> and 31197,<ref>{{cite web | title=Date | url=https://howardhinnant.github.io/date/date.html }}</ref> respectively. Windows epoch time is used to store timestamps for files<ref>{{cite web |title=File Times - Win32 apps |url=https://learn.microsoft.com/en-us/windows/win32/sysinfo/file-times |website=Microsoft Learn |date=7 January 2021 |publisher=Microsoft |access-date=9 March 2023 |archive-date=8 March 2023 |archive-url=https://web.archive.org/web/20230308222206/https://learn.microsoft.com/en-us/windows/win32/sysinfo/file-times |url-status=live }}</ref> and in protocols such as the [[Active Directory]] Time Service<ref>{{cite web |title=How to convert date/time attributes in Active Directory to standard time format |url=https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/convert-datetime-attributes-to-standard-format#summary |website=Microsoft Learn |publisher=Microsoft |access-date=20 October 2022 |archive-date=20 October 2022 |archive-url=https://web.archive.org/web/20221020181637/https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/convert-datetime-attributes-to-standard-format#summary |url-status=live }}</ref> and [[Server Message Block]].

The [[Network Time Protocol]] used to coordinate time between computers uses an epoch of 1&nbsp;January 1900, counted in an unsigned 32-bit integer for seconds and another unsigned 32-bit integer for fractional seconds, which rolls over every 2{{sup|32}} seconds (about once every 136 years).<ref name="StevensFenner2004">{{cite book |author1=W. Richard Stevens |author2=Bill Fenner |author3=Andrew M. Rudoff |title=UNIX Network Programming |url=https://books.google.com/books?id=ptSC4LpwGA0C&pg=PA582 |year=2004 |publisher=Addison-Wesley Professional |isbn=978-0-13-141155-5 |pages=582– |access-date=16 October 2016 |archive-url=https://web.archive.org/web/20190330170620/https://books.google.com/books?id=ptSC4LpwGA0C&pg=PA582 |archive-date=30 March 2019 |url-status=live}}</ref>

Many applications and programming languages provide methods for storing time with an explicit timezone.<ref>{{cite web |title=datetime — Basic date and time types |url=https://docs.python.org/3/library/datetime.html#available-types |website=Python Standard Library Reference |publisher=Python Software Foundation |access-date=20 October 2022 |quote=Attributes: year, month, day, hour, minute, second, microsecond, and tzinfo. |archive-date=19 October 2022 |archive-url=https://web.archive.org/web/20221019115837/https://docs.python.org/3/library/datetime.html#available-types |url-status=live }}</ref> There are also a number of time format standards which exist to be readable by both humans and computers, such as [[ISO 8601]].

== Notable events in Unix time ==
<!-- New entries to this list are subject to removal unless accompanied by a citation establishing notability -->
Unix enthusiasts have a history of holding "time_t parties" (pronounced "time [[Tea party|tea parties]]") to celebrate significant values of the Unix time number.<ref name="party-like-its=1234567890">{{Cite magazine |url=https://www.wired.com/gadgetlab/2009/02/unix-lovers-to/ |title=Unix Lovers to Party Like It's 1234567890 |magazine=Wired |last=Tweney |first=Dylan |date=12 February 2009 |access-date=12 March 2017 |archive-date=29 March 2014 |archive-url=https://web.archive.org/web/20140329022430/http://www.wired.com/gadgetlab/2009/02/unix-lovers-to/ |url-status=live }}</ref><ref>{{cite web |url=https://slashdot.org/story/05/03/17/169200/date-s-turning-1111111111 |title=Slashdot {{!}} date +%s Turning 1111111111 |date=17 March 2005 |access-date=12 January 2020 |archive-date=12 January 2020 |archive-url=https://web.archive.org/web/20200112103650/https://slashdot.org/story/05/03/17/169200/date-s-turning-1111111111 |url-status=live }}{{unreliable source?|date=May 2012}}</ref> 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 <code>time_t</code> values in decimal. Among some groups round [[binary numeral system|binary]] numbers are also celebrated,{{Citation needed|date=September 2019}} such as +2<sup>30</sup>, which occurred at 13:37:04 UTC on Saturday, 10&nbsp;January 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 seconds 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 18:36:57 UTC on Wednesday, 17&nbsp;October 1973, the first appearance of the date in [[ISO 8601]] format{{efn|cited retroactively since ISO 8601 was published in 1988.}} {{Nowrap|(1973-10-17)}} within the digits of Unix time (119731017) took place.
* At 01:46:40 UTC on Sunday, 9&nbsp;September 2001, the Unix billennium (Unix time number {{val|1000000000}}) was celebrated.<ref name="unixtime_facts">{{cite web|title=Unix time facts & trivia – Unix Time . Info|url=http://unixtime.info/facts.html|archive-url=https://web.archive.org/web/20171027205157/http://unixtime.info/facts.html|archive-date=27 October 2017}}</ref> The name ''billennium'' is a [[portmanteau]] of ''[[billion (word)|billion]]'' and ''[[millennium]]''.<ref>{{cite web |url=http://www.electromagnetic.net/press-releases/unixonebln.php |archive-url=https://archive.today/20130413172626/http://www.electromagnetic.net/press-releases/unixonebln.php |url-status=dead |archive-date=13 April 2013 |title=UNIX Approaches Ripe Old Age of One Billion |publisher=Electromagnetic.net |access-date=6 December 2012 }}</ref><ref>{{cite journal |url=http://catless.ncl.ac.uk/Risks/21.69.html#subj7 |title= The RISKS Digest, Volume 21 Issue 69|date=15 October 2001 |access-date=6 December 2012 |last1=Neumann |first1=Peter G. |journal=The Risks Digest |volume=21 |issue=69 |archive-date=22 October 2015 |archive-url=https://web.archive.org/web/20151022025543/http://catless.ncl.ac.uk/Risks/21.69.html#subj7 |url-status=live }}</ref> Some programs which stored timestamps using a text representation encountered sorting errors, as in a text sort, times after the turnover starting with a ''1'' digit erroneously sorted before earlier times starting with a ''9'' digit. Affected programs included the popular [[Usenet]] reader [[KNode]] and [[e-mail]] client [[KMail]], part of the [[KDE]] desktop environment. Such bugs were generally cosmetic in nature and quickly fixed once problems became apparent.{{citation needed|date=April 2023}} The problem also affected many ''Filtrix'' document-format filters provided with [[Linux]] versions of [[WordPerfect]]; a patch was created by the user community to solve this problem, since [[Corel]] no longer sold or supported that version of the program.<ref name="linu_Tech">{{Cite web | title = Technical Problems. | work = linuxmafia.com | access-date = 21 August 2017 | url = http://linuxmafia.com/wpfaq/problems.html#FITRIX | archive-date = 11 October 2012 | archive-url = https://web.archive.org/web/20121011065555/http://linuxmafia.com/wpfaq/problems.html#FITRIX | url-status = live }}</ref>
* {{anchor|1234567890 Day}}At 23:31:30 UTC on Friday, 13&nbsp;February 2009, the [[decimal]] representation of Unix time reached {{val|1234567890}} seconds.<ref>{{cite web|author=nixCraft |url=https://www.cyberciti.biz/tips/february-13th-unix-time-will-reach-1234567890.html |title=Humor: On Feb, Friday 13, 2009 Unix time Will Be 1234567890 |date=9 February 2009 |publisher=Cyberciti.biz |access-date=5 July 2023}}</ref> [[Google]] celebrated this with a [[Google Doodle]].<ref>{{cite web|title=Google 1234567890 Logo|url=https://www.google.com/logos/unix1234567890.gif|publisher=Google Inc.|access-date=28 January 2013|archive-date=11 January 2013|archive-url=https://web.archive.org/web/20130111012013/http://www.google.com/logos/unix1234567890.gif|url-status=live}}</ref> Parties and other celebrations were held around the world, among various technical subcultures, to celebrate the {{val|1234567890}}th second.<ref name="party-like-its=1234567890"/><ref>{{cite news |url=https://www.thetimes.co.uk/tto/technology/article1859315.ece |title=At the third stroke, the Unix time will be 1234567890 |newspaper=[[The Times]] |first=Murad |last=Ahmed |date=13 February 2009 |access-date=12 January 2020 |archive-date=14 November 2016 |archive-url=https://web.archive.org/web/20161114122531/http://www.thetimes.co.uk/tto/technology/article1859315.ece |url-status=dead }}</ref>

== In popular culture ==
[[Vernor Vinge]]'s novel ''[[A Deepness in the Sky]]'' describes a spacefaring trading civilization thousands of years in the future that still uses the Unix epoch. The "[[software archaeology|programmer-archaeologist]]" responsible for finding and maintaining usable code in mature computer systems first believes that the epoch refers to the time when [[Apollo 11|man first walked on the Moon]], but then realizes that it is "the 0-second of one of humankind's first computer operating systems".<ref name="mashey20041227">{{cite journal | title=Languages, Levels, Libraries, and Longevity | author=Mashey, John R. | author-link=John R. Mashey | journal=ACM Queue | date=27 December 2004 | volume=2 | issue=9 | pages=32–38 | doi=10.1145/1039511.1039532 | s2cid=28911378 | doi-access=free }}</ref>

== See also ==
* [[Epoch (computing)]]
* [[System time]]

== Notes ==
{{Notelist}}

== References ==
{{Reflist|30em}}

== External links ==
{{Wikiversity|JavaScript/Epoch time converter}}
* [https://www.bell-labs.com/usr/dmr/www/1stEdman.html Unix Programmer's Manual, first edition]
* [https://www.mail-archive.com/leapsecs@rom.usno.navy.mil/msg00109.html Personal account of the POSIX decisions] by [[Landon Curt Noll]]
* [https://howardhinnant.github.io/date_algorithms.html chrono-Compatible Low-Level Date Algorithms] – algorithms to convert between Gregorian and Julian dates and the number of days since the start of Unix time

{{Calendars}}

{{DEFAULTSORT:Unix Time}}
[[Category:Calendaring standards]]
[[Category:Network time-related software]]
[[Category:Time measurement systems]]
[[Category:Time scales]]
[[Category:Unix|Time]]
[[Category:1970 in computing]]