Unix time
Unix time
Main page
2119938

Unix time

logo
Community Hub0 subscribers
Read side by side
Unix time
View on Wikipedia
from Wikipedia

Unix time passed 1000000000 seconds on 2001-09-09T01:46:40Z.[1] It was celebrated in Copenhagen, Denmark, at a party held by the Danish UNIX User Group at 03:46:40 local time.

Unix time[a] is a date and time representation widely used in computing. It measures time by the number of non-leap seconds that have elapsed since 00:00:00 UTC on 1 January 1970, the Unix 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 granularity, such as microseconds or nanoseconds.

Definition

[edit]

Unix time is currently defined as the number of non-leap seconds which have passed since 00:00:00 UTC on Thursday, 1 January 1970, which is referred to as the Unix epoch.[3] Unix time is typically encoded as a signed integer.

The Unix time 0 is exactly midnight UTC on 1 January 1970, with Unix time incrementing by 1 for every non-leap second after this. For example, 00:00:00 UTC on 1 January 1971 is represented in Unix time as 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 UTC on 1 January 1969 is represented in Unix time as โˆ’31536000. Every day in Unix time consists of exactly 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.[5]

Leap seconds

[edit]

Unix time differs from both Coordinated Universal Time (UTC) and International Atomic Time (TAI) in its handling of leap seconds. 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 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 86400 seconds. Each leap second uses the timestamp of a second that immediately precedes or follows it.[3]

On a normal UTC day, which has a duration of 86400 seconds, the Unix time number changes in a continuous manner across midnight. For example, at the end of the day used in the examples above, the time representations progress as follows:

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 1095379198.75
2004-09-17T00:00:31.00 2004-09-16T23:59:59.00 1095379199.00
2004-09-17T00:00:31.25 2004-09-16T23:59:59.25 1095379199.25
2004-09-17T00:00:31.50 2004-09-16T23:59:59.50 1095379199.50
2004-09-17T00:00:31.75 2004-09-16T23:59:59.75 1095379199.75
2004-09-17T00:00:32.00 2004-09-17T00:00:00.00 1095379200.00
2004-09-17T00:00:32.25 2004-09-17T00:00:00.25 1095379200.25
2004-09-17T00:00:32.50 2004-09-17T00:00:00.50 1095379200.50
2004-09-17T00:00:32.75 2004-09-17T00:00:00.75 1095379200.75
2004-09-17T00:00:33.00 2004-09-17T00:00:01.00 1095379201.00
2004-09-17T00:00:33.25 2004-09-17T00:00:01.25 1095379201.25

When a leap second occurs, the UTC day is not exactly 86400 seconds long and the Unix time number (which always increases by exactly 86400 each day) experiences a 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:

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 915148798.75
1999-01-01T00:00:30.00 1998-12-31T23:59:59.00 915148799.00
1999-01-01T00:00:30.25 1998-12-31T23:59:59.25 915148799.25
1999-01-01T00:00:30.50 1998-12-31T23:59:59.50 915148799.50
1999-01-01T00:00:30.75 1998-12-31T23:59:59.75 915148799.75
1999-01-01T00:00:31.00 1998-12-31T23:59:60.00 915148800.00
1999-01-01T00:00:31.25 1998-12-31T23:59:60.25 915148800.25
1999-01-01T00:00:31.50 1998-12-31T23:59:60.50 915148800.50
1999-01-01T00:00:31.75 1998-12-31T23:59:60.75 915148800.75
1999-01-01T00:00:32.00 1999-01-01T00:00:00.00 915148800.00
1999-01-01T00:00:32.25 1999-01-01T00:00:00.25 915148800.25
1999-01-01T00:00:32.50 1999-01-01T00:00:00.50 915148800.50
1999-01-01T00:00:32.75 1999-01-01T00:00:00.75 915148800.75
1999-01-01T00:00:33.00 1999-01-01T00:00:01.00 915148801.00
1999-01-01T00:00:33.25 1999-01-01T00:00:01.25 915148801.25

Unix time numbers are repeated in the second immediately following a positive leap second. The Unix time number 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 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

[edit]

Commonly a 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.[6] This is what happens across a positive leap second:

Non-synchronous Mills-style Unix clock
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 915148798.75
1999-01-01T00:00:30.00 1998-12-31T23:59:59.00 TIME_INS 915148799.00
1999-01-01T00:00:30.25 1998-12-31T23:59:59.25 TIME_INS 915148799.25
1999-01-01T00:00:30.50 1998-12-31T23:59:59.50 TIME_INS 915148799.50
1999-01-01T00:00:30.75 1998-12-31T23:59:59.75 TIME_INS 915148799.75
1999-01-01T00:00:31.00 1998-12-31T23:59:60.00 TIME_INS 915148800.00
1999-01-01T00:00:31.25 1998-12-31T23:59:60.25 TIME_OOP 915148799.25
1999-01-01T00:00:31.50 1998-12-31T23:59:60.50 TIME_OOP 915148799.50
1999-01-01T00:00:31.75 1998-12-31T23:59:60.75 TIME_OOP 915148799.75
1999-01-01T00:00:32.00 1999-01-01T00:00:00.00 TIME_OOP 915148800.00
1999-01-01T00:00:32.25 1999-01-01T00:00:00.25 TIME_WAIT 915148800.25
1999-01-01T00:00:32.50 1999-01-01T00:00:00.50 TIME_WAIT 915148800.50
1999-01-01T00:00:32.75 1999-01-01T00:00:00.75 TIME_WAIT 915148800.75
1999-01-01T00:00:33.00 1999-01-01T00:00:01.00 TIME_WAIT 915148801.00
1999-01-01T00:00:33.25 1999-01-01T00:00:01.25 TIME_WAIT 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

[edit]

Another, much rarer, non-conforming variant of Unix time keeping involves incrementing the value for all seconds, including leap seconds;[7] some Linux systems are configured this way.[8] 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).[8]

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 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 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 TAI rather than 1970-01-01T00:00:10 TAI, was proposed for inclusion in ISO C's time.h, but only the UTC part was accepted in 2011.[9] A tai_clock does, however, exist in C++20.

Representing the number

[edit]

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 data type that represents a point in time is, on many platforms, a signed integer, traditionally of 32 bits (but 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 overflow in what is known as the year 2038 problem.

UUIDv7 encodes the Unix epoch timestamp (in milliseconds) in an unsigned 48-bit field. This representation is valid until the year 10889 AD.[10]

In some newer operating systems, time_t has been widened to 64 bits. This expands the times representable to about 292.3 billion years in both directions, which is over twenty times the present age of the universe.

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 the epoch. The consensus is for time_t 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 time_t, 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> 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. POSIX requires time_t 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 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).[11][12] These structures provide a decimal-based fixed-point data format, which is useful for some applications, and trivial to convert for others.

UTC basis

[edit]

The present form of UTC, with leap seconds, is defined only starting from 1 January 1972. Prior to that, since 1 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 timekeeping; in these eras, some approximation of GMT (based directly on the Earth's rotation) was used instead of an atomic timescale.[citation needed]

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 January 1970 (the Unix epoch) to 1 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 +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.[13] A likely means to execute this change is to define a new time scale, called International Time[citation needed], 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

[edit]

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. 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 January 1971 and 1 January 1972 both being used as epochs during Unix's early development. Early definitions of Unix time also lacked timezones.[14][15]

The current epoch of 1 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.[1]

When POSIX.1 was written, the question arose of how to precisely define time_t 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,[16] 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]

Usage

[edit]

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 APIs, 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 and C++. C's Unix time functions are defined as the system time API in the POSIX specification.[17] 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.[18][19][20]

iOS provides a Swift API which defaults to using an epoch of 1 January 2001 but can also be used with Unix timestamps.[21] Android uses Unix time alongside a timezone for its system time API.[22]

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.[18] Unix time is used in the PE format for Windows executables.[23]

Unix time is typically available in major programming languages and is widely used in desktop, mobile, and web application programming. Java provides an Instant object which holds a Unix timestamp in both seconds and nanoseconds.[24] Python provides a time library which uses Unix time.[25] 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.[26]

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.[27][28] Several archive file formats can store timestamps in Unix time, including RAR and tar.[29][30] Unix time is also commonly used to store timestamps in databases, including in MySQL and PostgreSQL.[31][32]

Limitations

[edit]

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.[33]

Range of representable times

[edit]
See also: Year 2038 problem
An animated visual of the 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 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 231 โˆ’ 1, and the minimum value is โˆ’231, 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.[33]:โ€Š60โ€Š[34]

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.[33]:โ€Š60-61โ€Š[35]

Alternatives

[edit]

Unix time is not the only standard for time that counts away from an epoch. The C# programming language's DateTime structure, the FILETIME type in Windows, and Azure Cosmos DB's GetCurrentTicks function store time as a count of 100-nanosecond intervals that have elapsed since 0:00 GMT on 1 January 1 AD,[36] 1 January 1601,[37] and 1 January 1970,[38] which will not overflow until the years 29228,[39][40] 30828,[39][41] and 31197,[42] respectively. Windows epoch time is used to store timestamps for files[43] and in protocols such as the Active Directory Time Service[44] and Server Message Block.

The Network Time Protocol used to coordinate time between computers uses an epoch of 1 January 1900, counted in an unsigned 32-bit integer for seconds and another unsigned 32-bit integer for fractional seconds, which rolls over every 232 seconds (about once every 136 years).[45]

Many applications and programming languages provide methods for storing time with an explicit timezone.[46] 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

[edit]

Unix enthusiasts have a history of holding "time_t parties" (pronounced "time tea parties") to celebrate significant values of the Unix time number.[47][48] 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 numbers are also celebrated,[citation needed] such as +230, which occurred at 13:37:04 UTC on Saturday, 10 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 October 1973, the first appearance of the date in ISO 8601 format[b] (1973-10-17) within the digits of Unix time (119731017) took place.[49]
  • At 01:46:40 UTC on Sunday, 9 September 2001, the Unix billennium (Unix time number 1000000000) was celebrated.[50] The name billennium is a portmanteau of billion and millennium.[51][52] 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] 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.[53]
  • At 23:31:30 UTC on Friday, 13 February 2009, the decimal representation of Unix time reached 1234567890 seconds.[54] Google celebrated this with a Google Doodle.[55] Parties and other celebrations were held around the world, among various technical subcultures, to celebrate the 1234567890th second.[47][56]
[edit]

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 "programmer-archaeologist" responsible for finding and maintaining usable code in mature computer systems first believes that the epoch refers to the time when man first walked on the Moon, but then realizes that it is "the 0-second of one of humankind's first computer operating systems".[57]

See also

[edit]

Notes

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Unix time

View on Grokipedia
from Grokipedia
Unix time, also known as POSIX time or epoch time, is a standard for representing instants in time as the number of seconds elapsed since the Unix epochโ€”00:00:00 UTC on 1 January 1970โ€”excluding leap seconds. This convention originated in early Unix operating systems and forms the basis for time representation in POSIX-compliant environments, where it is typically stored as a signed integer of type time_t.[1] The time() function in the C standard library returns the current Unix time as this value, enabling efficient arithmetic operations for date and time calculations across computing systems.[1] Widely adopted beyond Unix-like systems, Unix time underpins timestamping in file systems, databases, network protocols, and programming languages, including JavaScript's Date object (which uses milliseconds since the epoch) and HTTP headers for caching and expiration. Its simplicity facilitates interoperability but introduces challenges: it ignores leap seconds, treating every day as exactly 86,400 seconds, which can cause discrepancies of up to 27 seconds (the total of 27 leap seconds added since 1970, as of November 2025) when converting to or from UTC. Additionally, on systems using a 32-bit signed time_t, the maximum value of 2,147,483,647 seconds is reached at 03:14:07 UTC on 19 January 2038, triggering the Year 2038 problemโ€”potential overflows leading to incorrect time representations or system failures.[2] To address these limitations, modern POSIX implementations increasingly use 64-bit time_t for extended range (up to year 292 billion), and extensions like struct timespec provide nanosecond precision via tv_sec (seconds since epoch) and tv_nsec (nanoseconds).[3] Despite ongoing transitions, Unix time remains a foundational element in computing due to its portability and efficiency.

Fundamentals

Definition

Unix time, also known as POSIX time, is a system for representing points in time as the number of seconds that have elapsed since the Unix epoch of 1970-01-01T00:00:00 UTC, excluding leap seconds in standard implementations.[1][4] This results in a fixed 86,400 seconds per day, providing a simple, machine-readable timestamp that aligns with Coordinated Universal Time (UTC).[1] This representation treats time as a proleptic Gregorian calendar timestamp, extending the Gregorian calendar rules backward indefinitely from the epoch starting at 1970-01-01 00:00:00 UTC.[1] The proleptic extension assumes the same leap year rules apply before the historical introduction of the Gregorian calendar in 1582. In standard POSIX-compliant systems, Unix time is typically stored using the signed integer type time_t, which allows representation of dates both before (negative values) and after the epoch (positive values).[1] Some non-standard implementations may use unsigned integers, limiting representation to post-epoch times only.[1] The value is computed as Unix time = floor((current UTC time - epoch) / 1 second).[1]

Epoch

The Unix epoch serves as the zero point for Unix time, defined as 00:00:00 UTC on Thursday, January 1, 1970.[5][6] This specific date marks the beginning of the 1970s decade and was selected as a convenient reference point close to the period of Unix's initial development in the late 1960s and early 1970s, adjusted to center the representable time range for early 32-bit implementations.[7] Unix time extends proleptically to dates before the epoch, where timestamps become negative integers representing seconds elapsed prior to 1970-01-01 00:00:00 UTC.[8] These negative values follow the proleptic Gregorian calendar, which applies Gregorian rules backward indefinitely, enabling consistent date representations for historical periods.[9] In date calculations, Unix timestamps inherently denote UTC, requiring conversion to local time by applying the appropriate time zone offset.[10] These offsets account for variations due to daylight saving time, which implementations like the POSIX mktime() function determine based on local rules to yield accurate local timestamps.[10] Proper handling of historical DST changes is essential to avoid discrepancies in pre-epoch or transitional periods.[10]

Numeric Representation

Unix time is conventionally encoded as a signed integer value representing the number of whole seconds that have elapsed since the Unix Epoch of 1970-01-01 00:00:00 UTC. In the POSIX standard, this value is stored in the time_t data type, an arithmetic type suitable for representing calendar time as seconds since the Epoch.[1] Historical implementations typically employed a 32-bit signed integer for time_t, limiting the representable range to a maximum of 231โˆ’1=[2147483647](/page/2,147,483,647)2^{31} - 1 = [2147483647](/page/2,147,483,647) seconds after the Epoch, which equates to 03:14:07 UTC on 19 January 2038.[1][11] To arrive at this date, divide the maximum seconds by 86,400 (seconds per day) to get approximately 24,855.02 days, then add this duration to the Epoch date, accounting for Gregorian calendar rules (including leap years), yielding 19 January 2038 at the specified time. Contemporary systems often use a 64-bit signed integer for time_t, expanding the maximum value to 263โˆ’1=92233720368547758072^{63} - 1 = 9223372036854775807 seconds, or roughly 292 billion years into the future (calculated as (263โˆ’1)/(365.25ร—[86,400](/page/86400))โ‰ˆ292,277,026,596(2^{63} - 1) / (365.25 \times [86{,}400](/page/86_400)) \approx 292{,}277{,}026{,}596 years).[1][12] The conversion between Unix time and a human-readable date follows a straightforward additive formula: the timestamp $ t $ is the integer seconds since the Epoch, so the corresponding UTC datetime is the Epoch plus $ t $ seconds. This can be expressed as:
UTC datetime=1970โˆ’01โˆ’01 00:00:00 UTC+t seconds \text{UTC datetime} = 1970{-}01{-}01~00:00:00~\text{UTC} + t~\text{seconds}
where $ t $ is the Unix timestamp. Libraries and functions in programming languages implement this by adjusting for Gregorian calendar irregularities, such as leap days, but exclude leap seconds in the count.[1] For greater precision beyond whole seconds, Unix time APIs often incorporate fractional components through auxiliary fields. For instance, the gettimeofday function returns time in a struct timeval, comprising tv_sec (the time_t seconds) and tv_usec (microseconds, ranging from 0 to 999,999). This allows sub-second resolution up to 1 microsecond.[13] Similar structures exist in other APIs, such as nanosecond precision in struct timespec used by clock_gettime. When storing Unix timestamps in binary formats, such as files or network packets, endiannessโ€”the byte order of multi-byte integersโ€”plays a critical role in ensuring interoperability across heterogeneous systems. Unix systems may be big-endian (most significant byte first, common in network protocols) or little-endian (least significant byte first, typical in x86 architectures), so explicit conversion to a standard order, like network byte order, is recommended for portable storage.[14]

Timekeeping Basis

UTC Alignment

Unix time is based on Coordinated Universal Time (UTC), representing the number of seconds elapsed since the epoch of 1970-01-01 00:00:00 UTC.[15] This alignment ensures that Unix timestamps correspond to specific instants in the UTC timescale, providing a standardized reference for global timekeeping in computing systems.[15] UTC serves as the international time standard, coordinated by the International Bureau of Weights and Measures (BIPM) and derived from International Atomic Time (TAI), which is a continuous scale based on atomic clocks realizing the SI second.[16] Leap seconds are periodically inserted into UTCโ€”based on recommendations from the International Earth Rotation and Reference Systems Service (IERS)โ€”to maintain its proximity to solar time, with the difference between UTC and TAI currently at 37 seconds as of 2025.[16] In contrast to UTC's adjustments, Unix time ignores leap seconds entirely, advancing at a constant rate of one second per SI second and treating each day as precisely 86,400 seconds. This omission, as required by POSIX standards, results in Unix time gradually diverging from UTC by the cumulative number of leap seconds introduced since the epoch, but it preserves a strictly monotonic count. The monotonic nature of Unix time makes it ideal for measuring durations and elapsed intervals, where subtracting two timestamps yields the exact number of seconds passed, unaffected by UTC's irregularities. Conversion between Unix time and UTC-readable formats, such as ISO 8601, typically involves system library functions that interpret the timestamp relative to the epoch and generate a formatted string in UTC.[17] For instance, the POSIX gmtime() function breaks down a time_t value into year, month, day, hour, minute, and second components assuming continuous counting from the epoch, which can then be rendered in ISO 8601 notation (e.g., "2025-11-08T12:00:00Z") while distributing the effect of ignored leap seconds across the calendar representation. This process ensures compatibility for protocols and applications requiring both compact numeric storage and standardized textual output.[17]

Leap Seconds

Leap seconds are one-second adjustments occasionally inserted into Coordinated Universal Time (UTC) to compensate for variations in Earth's rotation rate, which causes the length of the solar day to differ slightly from the uniform SI second defined by atomic clocks.[18] These adjustments are introduced irregularly, typically at the end of June or December, to keep UTC within 0.9 seconds of UT1, the solar time scale based on Earth's rotation.[18] Since the practice began in 1972, 27 leap seconds have been added to UTC.[18] Standard Unix time, also known as POSIX time, excludes these leap seconds from its measurement, counting only non-leap SI seconds since the epoch of January 1, 1970, 00:00:00 UTC and treating every day as precisely 86,400 seconds long.[17] Consequently, Unix time cannot represent the leap second notation 23:59:60 in UTC, instead remaining continuous by advancing directly from 23:59:59 to 00:00:00 the next day, effectively skipping the extra second.[19] As a result, Unix time gradually diverges from UTCโ€”and thus from solar timeโ€”by the total number of leap seconds inserted since the epoch, leading to a current offset of 27 seconds where Unix time lags behind UTC as of November 2025.[18] To mitigate issues arising from this exclusion, several variants address leap second handling in Unix time systems. TAI-based approaches rely on International Atomic Time (TAI), a continuous scale without leap seconds that counts uniform SI seconds from the same atomic reference; TAI currently leads UTC by 37 seconds due to the initial 10-second offset at the start of UTC plus the 27 accumulated leaps.[18] POSIX-compliant systems incorporate adjustments by using leap second tables to correct timestamps when converting to or from UTC, ensuring applications can account for the discrepancies without altering the core Unix count. In Network Time Protocol (NTP) implementations, the non-synchronous variant applies leap second smearing to distribute the adjustment evenly over a prolonged interval, such as 17 hours, preventing sudden clock jumps that could disrupt time-sensitive operations; this method, originally proposed for large-scale systems, is now part of NTP best current practices to maintain smooth synchronization.[20] The leap-counting variant, in contrast, explicitly tracks and adds each leap second to the Unix timestamp during synchronization or conversion processes, allowing precise alignment with UTC by maintaining a running total of accumulated leaps from authoritative sources like IERS Bulletins.[20] As of 2025, with 27 leap seconds accumulated and international agreements set to abolish further insertions by 2035, the 37-second offset between TAI and UTC will stabilize, though Unix time's 27-second drift from UTC will persist without ongoing corrections.[18][20]

Historical Development

Origins in Unix

Unix time originated in the early development of the Unix operating system at Bell Labs in the early 1970s. It was defined in the first edition of the Unix Programmer's Manual from November 1971 as a 32-bit quantity representing sixtieths of a second since January 1, 1971, 00:00:00 UTC, reflecting the hardware's clock tick rate and the need for sub-second precision in early implementations on the PDP-11 minicomputer.[21] This representation was designed to efficiently track temporal data within the constraints of the PDP-11's 16-bit architecture, utilizing a 32-bit integer to store time values, which aligned with the machine's word size for two consecutive 16-bit registers.[22] Initially, Unix time was employed for critical system functions, including recording file modification times in the inode structure and supporting process scheduling by providing a uniform measure of elapsed time.[21] This granular unit allowed for accurate timestamping but limited the range to approximately 2.5 years due to the 32-bit constraint.[22] To prevent overflows, the epoch was adjusted multiple times during the 1969โ€“1973 period, including a brief use of January 1, 1972, as the starting point, with existing files back-dated to align. By the mid-1970s, the representation had evolved to seconds since the Unix epoch of January 1, 1970, 00:00:00 UTC, extending the usable range. This adjustment provided a symmetrical timeline of about 68 years from the PDP-11's perspective with a 32-bit signed integer. The Version 7 Unix manual from 1979 formally documents this standardized form, where the time(2) system call returns the current time as the number of seconds elapsed since the 1970 epoch.[22]

Standardization

The formal standardization of Unix time began with its inclusion in the IEEE Std 1003.1-1988, also known as POSIX.1, which established it as the basis for time representation in portable operating systems. This standard defined key functions such as time(), which returns the current time as the number of seconds since the Unix epoch (January 1, 1970, 00:00:00 UTC), and utime(), which sets file access and modification times using this representation.[1][23] POSIX.1 ensured portability across Unix-like systems by specifying that implementations must support this integer-based counting of non-leap seconds, excluding leap seconds from the count.[1] Subsequent revisions of IEEE Std 1003.1 extended Unix time capabilities to address growing needs for precision and range. For instance, POSIX.1-2001 introduced clock_gettime() and the timespec structure, enabling sub-second precision down to nanoseconds while maintaining compatibility with the traditional time_t type. Regarding range limitations, POSIX.1-2008 raised awareness of the Year 2038 problem, where 32-bit signed time_t implementations would overflow after 2,147,483,647 seconds (corresponding to 2038-01-19 03:14:07 UTC), though it did not mandate a 64-bit transition; many systems adopted 64-bit time_t voluntarily to extend the range to 292 billion years.[1] The ISO/IEC 9899 standard for the C programming language indirectly supported Unix time through the time_t type, defined as an arithmetic type capable of representing times, with functions like time() relying on POSIX for the specific epoch and encoding.[3] Beyond Unix systems, Unix time gained widespread adoption in non-Unix environments; for example, Microsoft's C runtime library (MSVCRT) implements time() to return seconds since the Unix epoch, facilitating portability on Windows NT and later versions.[24] Similarly, Java's System.currentTimeMillis() provides milliseconds since the epoch, enabling cross-platform timestamp handling in applications. This global influence underscores Unix time's role as a de facto standard for interoperable timekeeping in diverse computing ecosystems.

Practical Applications

In Operating Systems

In Unix-like operating systems, Unix time serves as the foundational representation for the system clock, enabling precise tracking of wall-clock time for kernel operations. The Linux kernel, for instance, maintains the current time as seconds and nanoseconds since the Unix epoch (January 1, 1970, 00:00:00 UTC), accessible via system calls such as gettimeofday(), which returns this value in a struct timeval for use in process scheduling, event logging, and time-sensitive kernel decisions.[25] This integration ensures that kernel subsystems, including the scheduler, can timestamp events relative to absolute real-world time rather than just monotonic counters like jiffies, which measure kernel uptime in ticks but are converted or supplemented with Unix time for logging and external synchronization.[26] File systems in these operating systems store timestamps using Unix time to record key metadata about files and directories. In the ext4 file system, widely used in Linux distributions, each inode contains four timestamps: access time (atime), modification time (mtime), change time (ctime), and creation time (crtime, introduced in ext4), all represented as 64-bit values counting seconds (and nanoseconds for finer granularity) since the Unix epoch.[27] These timestamps track when a file was last read (atime), when its content was modified (mtime), when its metadata was altered (ctime), and when it was created (crtime), supporting features like backup utilities, auditing, and file integrity checks without requiring additional conversions.[27] To maintain accuracy, Unix-like systems synchronize their Unix time-based clocks with external references. On boot, the kernel initializes the system clock from the hardware real-time clock (RTC), a battery-backed device that persists time across power cycles, using interfaces like the hwclock utility to load RTC values into the kernel's timekeeping structure.[26] During operation, NTP daemons such as ntpd or chronyd adjust the system clock against remote servers, applying gradual corrections (slewing) or step adjustments to align with Coordinated Universal Time (UTC), compensating for clock drift typically in the range of milliseconds per day.[26] Variants of Unix-like systems also leverage Unix time for file system operations, often with adaptations for legacy formats. In macOS and BSD derivatives like FreeBSD, the UFS (Unix File System) stores inode timestamps directly as seconds since the Unix epoch, mirroring the standard Unix model for atime, mtime, and ctime to ensure compatibility with POSIX APIs. macOS, built on a Unix foundation, uses Unix time system-wide for its APFS file system (default since macOS High Sierra in 2017), storing timestamps natively as 64-bit values representing nanoseconds since the Unix epoch via kernel and user-space APIs like stat() for seamless integration.[28] Even non-Unix systems like Windows incorporate Unix time through internal conversions; the NTFS file system uses the FILETIME structure (100-nanosecond intervals since January 1, 1601), but Windows APIs and subsystems convert these to Unix time_t equivalents for interoperability with Unix-compatible tools and protocols.

In Programming and Software

In programming and software development, Unix time serves as a foundational representation for handling timestamps across various languages, libraries, and protocols. The C standard library, as defined in POSIX standards, provides core functions for manipulating Unix time values. The time() function retrieves the current calendar time as the number of seconds elapsed since the Unix epoch (January 1, 1970, 00:00:00 UTC), returning it as a time_t integer value. Complementary functions like localtime() convert a time_t value into a broken-down time structure (struct tm) adjusted for the local timezone, facilitating human-readable date components such as year, month, and hour. Conversely, mktime() performs the inverse operation, taking a local struct tm and normalizing it to produce a time_t Unix time value, handling ambiguities like daylight saving time transitions. Many programming languages expose Unix time through built-in modules or classes, often extending it to higher precision for modern applications. In Python, the time module's time.time() function returns the current Unix time as a floating-point number of seconds since the epoch, allowing sub-second accuracy via the fractional part.[29] This value can be converted to a structured format using time.localtime() or formatted as a string with time.strftime(). Similarly, in JavaScript, the Date.now() static method returns the Unix time in milliseconds since the epoch as an integer, which is useful for high-resolution timing in web applications; for instance, Date.now() yields a value like 1763164800000 for November 15, 2025, 00:00:00 UTC. Unix time is widely adopted in database systems for efficient storage and querying of temporal data. In MySQL, the TIMESTAMP data type internally stores values as the number of seconds since the Unix epoch, supporting automatic updates and timezone conversions while occupying four bytes per value. This format enables straightforward arithmetic operations, such as calculating time differences, and integrates with SQL functions like UNIX_TIMESTAMP() to convert between string dates and Unix time integers. In web protocols, Unix time underpins calculations for headers like HTTP's Date field, which specifies origination time in RFC 7231 format (e.g., "Wed, 21 Oct 2015 07:28:00 GMT"), but servers often compute these from internal Unix time representations for precision and portability.[30] For data interchange in networked applications, JSON and REST APIs frequently serialize dates as Unix timestamps to minimize payload size and parsing overhead, representing times as numeric integers or floats rather than verbose strings. This approach ensures interoperability across clients and servers, as demonstrated by libraries such as Luxon, which provides methods like DateTime.fromSeconds() to instantiate date objects from Unix time values and handle conversions to formatted outputs.[31]

Limitations and Challenges

Finite Timestamp Range

Unix time, when implemented using a signed 32-bit integer for the time_t type, faces a critical limitation due to integer overflow. The maximum value of 2,147,483,647 seconds since the Unix epoch (January 1, 1970, 00:00:00 UTC) corresponds to January 19, 2038, at 03:14:07 UTC.[32] At this point, adding one more second causes the value to wrap around to -2,147,483,648, equivalent to December 13, 1901, 20:45:52 UTC, potentially leading to erroneous date calculations, system crashes, or security vulnerabilities in affected software.[11] This issue, known as the Year 2038 problem or Y2K38, primarily impacts 32-bit systems and legacy applications that have not been updated.[33] To address this finite range, Unix time implementations have transitioned to 64-bit signed integers, expanding the representable duration significantly. A signed 64-bit time_t can hold up to 9,223,372,036,854,775,807 seconds after the epoch, corresponding to December 4, 292,277,026,596 CE, at 15:30:07 UTCโ€”far beyond any practical human timescale.[34] This extension effectively eliminates overflow concerns for the foreseeable future while maintaining compatibility with the Unix epoch convention. Mitigation strategies focus on API and kernel-level updates to support 64-bit time representations without breaking existing 32-bit applications. In glibc, the Time64 API provides Y2038-safe functions and types, such as __time64_t and clock_gettime64, which replace 32-bit equivalents when the feature macro _TIME_BITS=64 is defined during compilation.[35] This allows 32-bit systems to use 64-bit time values via compatible system calls, with glibc mapping legacy APIs to their 64-bit counterparts for backward compatibility. In the Linux kernel, support for 64-bit time was integrated starting with version 5.6 in 2020, including reworked timekeeping structures and new system calls like clock_gettime64 to handle 64-bit timestamps even on 32-bit architectures.[36] As of 2025, adoption of 64-bit time support is widespread on server environments, where nearly all modern hardware uses 64-bit architectures like x86-64 or ARM64, enabling seamless migration to 64-bit time_t. However, embedded systems and IoT devices lag behind, with 32-bit microcontrollers still comprising approximately 44% of the IoT market in 2024 and growing more slowly at a projected CAGR of 17.23% for 64-bit alternatives through 2030.[37] This disparity raises concerns for long-lived IoT deployments, such as industrial sensors or medical devices, where unpatched 32-bit software could face operational failures or exploit risks by 2038.[38]

Handling of Leap Seconds

Leap seconds introduce discontinuities into Coordinated Universal Time (UTC), causing system clocks to either repeat the final second of the day or insert an extra second, which results in non-monotonic time progression. This irregularity disrupts assumptions in software that expect continuously increasing timestamps, leading to potential errors in event ordering, logging, and resource scheduling, especially in distributed systems where precise synchronization across nodes is essential for coordinating tasks and preventing race conditions. For instance, in environments relying on Network Time Protocol (NTP) for synchronization, the sudden step can cause clocks to appear to move backward briefly, exacerbating issues in high-precision applications like financial transactions or telecommunications.[39][40] To address these challenges, several solutions have been developed at the system level. One prominent approach is leap smearing, which distributes the extra second gradually over an extended periodโ€”typically 24 hoursโ€”via incremental adjustments to NTP offsets, ensuring time remains monotonic without abrupt jumps. Google employs this technique in its public NTP service, applying a linear smear of approximately 0.7 milliseconds per update before and after the leap second to maintain seamless operation across its infrastructure and APIs. POSIX standards also support leap second handling through flags in time-related functions, such as the tm_sec field in struct tm, which permits values from 0 to 60 to indicate the insertion, allowing applications and kernels to detect and process the adjustment without halting operations.[41][42] The practical impact of leap seconds on software has been significant, highlighting vulnerabilities in various implementations. Prior to fixes in 2013, Java Remote Method Invocation (RMI) systems were prone to crashes during leap seconds due to their reliance on monotonic time for thread synchronization and lease renewals, resulting in infinite loops or timeouts when time appeared to regress. Similarly, systemd-timesyncd, the lightweight NTP client integrated into modern Linux distributions like those using systemd, mitigates leap seconds by deferring adjustments to the kernel, which applies the correction automatically upon receiving NTP leap indicators, preventing disruptions in user-space applications. The 2012 leap second insertion notably caused widespread outages, including at Qantas Airlines where the Amadeus reservation system failed for over two hours, forcing manual check-ins for more than 400 flights and stranding thousands of passengers.[43][44][45] These recurring issues have fueled an international debate on the future of leap seconds, with proposals to abolish them by 2035 to eliminate the risks to global digital infrastructure. The International Telecommunication Union (ITU) and the International Bureau of Weights and Measures (BIPM) have endorsed a resolution to discontinue leap second insertions after that date, allowing UTC to drift gradually from Earth's rotation without periodic corrections, thereby prioritizing stability in computing systems over astronomical precision.[46][47]

Complementary Systems

Alternative Time Standards

International Atomic Time (TAI) provides a continuous scale of atomic seconds without adjustments for leap seconds, making it suitable for high-precision scientific applications such as physics experiments and satellite operations.[18] As of November 2025, TAI is ahead of UTC by 37 seconds, reflecting the cumulative leap seconds inserted since 1972.[18] This offset ensures TAI maintains a steady progression independent of Earth's irregular rotation, contrasting with Unix time's alignment to UTC.[48] GPS time, utilized in the Global Positioning System, operates on a similar continuous basis to TAI but with a distinct epoch starting at 00:00:00 UTC on January 6, 1980.[49] It excludes leap second adjustments, resulting in an offset of 18 seconds ahead of UTC as of 2025.[50] This design supports precise navigation and timing in satellite signals, differing from Unix time's 1970 epoch and second-based granularity.[49] Windows FILETIME represents timestamps as 64-bit integers counting 100-nanosecond intervals since 00:00:00 UTC on January 1, 1601, originating from the Gregorian calendar's implementation in early Microsoft systems.[51] This format offers sub-second precision for file metadata and system events in Windows environments, unlike Unix time's coarser whole-second increments from a later epoch.[52] The Julian Day Number (JDN) serves astronomy by assigning a unique integer to each whole solar day, commencing at noon Universal Time on January 1, 4713 BCE in the proleptic Julian calendar.[53] It facilitates calculations of celestial events and long-term ephemerides without calendar irregularities, providing a day-count scale rather than Unix time's second-based chronology.[54] ISO 8601 standardizes human-readable date and time representations, such as YYYY-MM-DDTHH:MM:SSZ for UTC, to ensure unambiguous international communication.[55] In computing, it is frequently generated from Unix time values for logging, APIs, and data exchange, emphasizing readability over the compact numerical format of Unix timestamps.[55]

Interoperability with Unix Time

Unix time, representing seconds since the 1970-01-01 00:00:00 UTC epoch, requires specific conversions for interoperability with other time standards like GPS and TAI to ensure accurate synchronization across systems.[56] To convert Unix time to GPS time, which counts seconds since the 1980-01-06 00:00:00 UTC/GPS epoch without leap second insertions, the formula is:
GPS time=Unix timeโˆ’315964800+number of leap seconds since 1980 \text{GPS time} = \text{Unix time} - 315964800 + \text{number of leap seconds since 1980}
The constant 315964800 accounts for the 10-year and 5-day epoch difference (3657 days ร— 86400 seconds/day), while adding the cumulative leap seconds (currently 18 since the GPS epoch) adjusts for UTC's irregularities relative to GPS's continuous count.[57][58] For conversion to International Atomic Time (TAI), a continuous scale without leap seconds, the formula is:
TAI=Unix time+total leap seconds offset \text{TAI} = \text{Unix time} + \text{total leap seconds offset}
This offset, currently 37 seconds (10 seconds at the Unix epoch plus 27 leap seconds inserted since 1972), bridges Unix time's UTC basis to TAI's uniform SI seconds.[59][60] Programming interfaces facilitate these bridges; for example, Python's datetime.utcfromtimestamp(timestamp) converts a Unix timestamp to a UTC-aware datetime object, enabling further manipulations like timezone adjustments or sub-second handling via the datetime module.[56] In the Network Time Protocol (NTP), offsets are managed by subtracting 2208988800 seconds (70 years from NTP's 1900 epoch to Unix's 1970 epoch) during synchronization, allowing NTP servers to align system clocks with Unix time while compensating for network delays up to millisecond precision.[61][62] Challenges arise in these conversions, particularly with sub-second precision, as traditional Unix time uses integer seconds, potentially truncating fractional components (e.g., milliseconds from GPS) unless extended formats like struct timespec are employed, leading to loss in applications requiring microsecond accuracy.[63] Timezone conversions compound this, relying on the IANA tzdata database to map Unix timestamps from UTC to local times, accounting for historical offsets and daylight saving transitions, but mismatches in tzdata versions across systems can introduce discrepancies of hours.[64] Libraries such as libntp from the NTP distribution provide hybrid clock mechanisms that integrate Unix time with NTP adjustments for seamless synchronization, often combining physical clock reads with logical offsets to mitigate drift.[65] In IoT environments, these are critical for syncing GPS-derived timestamps to Unix time, as seen in protocols using libraries like those in Linux PTP implementations, ensuring devices maintain coherence for timing-sensitive tasks like sensor data logging.[66][67]

Key Milestones

Significant Timestamps

Unix time begins at the epoch value of 0, corresponding to 1970-01-01 00:00:00 UTC, marking the arbitrary starting point for measuring elapsed seconds in the system as defined by POSIX standards.[1] One notable milestone is the "Unix millennium" at 1,000,000,000 seconds, which occurred on 2001-09-09 01:46:40 UTC and was celebrated by technology communities as a symbolic anniversary of the epoch.[7] The sequential curiosity of 1,234,567,890 seconds fell on 2009-02-13 23:31:30 UTC, drawing attention from programmers for its aesthetically pleasing digit sequence and prompting informal observances in online forums and events.[68] Another round-number milestone reached 1,600,000,000 seconds on 2020-09-13 12:26:40 UTC, noted in programming communities for its clean numeric value.[69] The Unix timestamp 1640995200 corresponds to January 1, 2022, 00:00:00 UTC.[70] The Unix timestamp 1,751,314,974 corresponds to Monday, June 30, 2025, 20:22:54 UTC.[70] A significant future threshold is 2,147,483,647 seconds, representing the maximum value for a signed 32-bit integer and equivalent to 2038-01-19 03:14:07 UTC, after which systems relying on this format face potential overflow issues.[33]

Cultural and Media References

Unix time has permeated popular culture through celebrations of its milestones, depictions in films, and viral internet phenomena. On September 9, 2001, the Unix timestamp reached 1,000,000,000 seconds since the epoch, prompting global events and online commemorations dubbed the "New Billennium." The Danish UNIX User Group hosted a party in Copenhagen, while websites and forums like Linux.com organized virtual gatherings to mark the occasion, highlighting Unix time's role in computing history.[71][7] In cinema, Unix time indirectly influences portrayals of hacker culture, with films nodding to its foundational role in Unix systems. The 1995 film Hackers features explicit references to Unix literature, including props like International UNIX Environments and The Design and Implementation of the 4.3BSD Unix Operating System, underscoring the era's reverence for Unix as the bedrock of computing and hacking narratives.[72] Similarly, the iconic "digital rain" code in The Matrix (1999) evokes timestamp-like cascading counters, symbolizing the simulated world's temporal mechanics rooted in computational timekeeping. These elements have cemented Unix time's association with cyberpunk aesthetics in media. Artistic and meme culture has embraced Unix time's sequential elegance, particularly round numbers like 1,234,567,890, which occurred on February 13, 2009, at 23:31:30 UTC. This timestamp sparked widespread sharing on early social platforms and blogs, with developers hosting "party like it's 1234567890" events to celebrate its palindromic appeal, turning an abstract metric into a geeky cultural touchstone.[73] As of 2025, awareness of the impending Year 2038 problemโ€”where 32-bit Unix timestamps overflowโ€”has surged in tech media and podcasts, drawing parallels to the Y2K crisis. Outlets like SecurityWeek and Yahoo News have published articles framing Y2K38 as a looming vulnerability exploitable today, while episodes of This Week in Tech discuss mitigation strategies, urging updates to 64-bit systems.[38][74][75] Unix time also appears in video games, notably in save file structures. Minecraft worlds store last-access timestamps in level.dat files as Unix epoch seconds (or milliseconds in some formats), with region files using 32-bit integers for chunk modifications, occasionally leading to humorous "1970 creation date" glitches when values default to zero.[76]

References

  1. time
  2. Avoiding the year 2038 problem (GNU Gnulib)
  3. <time.h>
  4. time(2) - Linux manual page - man7.org
  5. 4. General Concepts
  6. Weekday Calculator: What Day Is It? - Time and Date
  7. Why Was 1 January 1970 Used as the Epoch Time? - Baeldung
  8. Why is 1/1/1970 the "epoch time"? - Stack Overflow
  9. Seconds Since the Epoch - Aphyr
  10. Google\Protobuf\Timestamp
  11. mktime
  12. What is the Year 2038 problem? - Computer | HowStuffWorks
  13. Why does the year 2038 problem occur in the first place?
  14. gettimeofday
  15. Unix Incompatibility Notes: Byte Order - Jan Wolter
  16. time
  17. BIPM technical services: Time Metrology
  18. RFC 3339 - Date and Time on the Internet: Timestamps
  19. Leap second and UT1-UTC information | NIST
  20. RFC 8633 - Network Time Protocol Best Current Practices
  21. [PDF] The UNIX Time-Sharing System* - Nokia
  22. [PDF] The Restoration of Early UNIX Artifacts - USENIX
  23. Unix Manual, first edition - Nokia
  24. utime
  25. time, _time32, _time64 - Microsoft Learn
  26. gettimeofday(2) - Linux manual page - man7.org
  27. ktime accessors - The Linux Kernel documentation
  28. 4.1. Index Nodes โ€” The Linux Kernel documentation
  29. https://docs.python.org/3/library/time.html#time.time
  30. https://datatracker.ietf.org/doc/html/rfc7231#section-7.1.1.1
  31. Based on thousands of APIs, what is the best approaches ... - Moesif
  32. The Year 2038 Problem - What it is, Why it will happen & How to fix it
  33. 2038 Bug Survival Guide: Lessons From Leap Year Code Issues
  34. Year 2038 Timestamp Problem - LinuxReviews
  35. Y2038ProofnessDesign - glibc wiki - Sourceware
  36. Approaching the kernel year-2038 end game - LWN.net
  37. IoT Microcontroller Market Size, Share & Trend Analysis, 2030
  38. The Y2K38 Bug Is a Vulnerability, Not Just a Date Problem ...
  39. [PDF] Leap-second considerations in distributed computer systems
  40. Resolve Leap Second Issues in Red Hat Enterprise Linux
  41. Leap Smear | Public NTP - Google for Developers
  42. <time.h>
  43. 'Leap Second' Bug Wreaks Havoc Across Web - WIRED
  44. systemd-timesyncd - ArchWiki
  45. Leap second hits Qantas air bookings, while Reddit and Mozilla stutter
  46. [PDF] The future of Coordinated Universal Time - ITU
  47. It's Official: The Leap Second Will Be Retired (a Decade from Now)
  48. International Atomic Time (TAI) - Time and Date
  49. Standard of time definition: UTC, GPS, LORAN and TAI - Ipses
  50. What is the GPS Clock? | GPS Timing | TimeTools Ltd
  51. FILETIME (minwinbase.h) - Win32 apps | Microsoft Learn
  52. File Times - Win32 apps - Microsoft Learn
  53. About Julian Dates | aavso
  54. Julian Day - Orbital Mechanics & Astrodynamics
  55. International standard date and time notation
  56. datetime โ€” Basic date and time types โ€” Python 3.14.0 documentation
  57. GPS Time Conversion Algorithm
  58. time - Ticks between Unix epoch and GPS epoch - Stack Overflow
  59. Leap seconds, Unix time, and TAI time
  60. UTC, TAI, and UNIX time
  61. RFC 5905 - Network Time Protocol Version 4 - IETF Datatracker
  62. RFC 1305: Network Time Protocol (Version 3) Specification ...
  63. How precise should I encode a Unix Time? - Stack Overflow
  64. Theory and pragmatics of the tz code and data
  65. How NTP Works
  66. Synchronizing Time with Linux* PTP
  67. Overview of Time Synchronization for IoT Deployments: Clock ...
  68. Unix Tick Tocks to a Billion - WIRED
  69. Unix Lovers to Party Like It's 1234567890 - WIRED
  70. WHO Director-General's opening remarks at the media briefing on ...
  71. New Billennium Party for the Unix epoch - Linux.com
  72. Hackers (1995) - FAQ - IMDb
  73. Time to Party Like it's 1234567890 ยป Feross.org
  74. New Millennium Bug? The Dangers of the Y2K38 Problem
  75. This Week in Tech 1043 Transcript - TWiT Network
  76. Java Edition level format - Minecraft Wiki
  77. POSIX Rationale (Seconds Since the Epoch)
  78. Epoch Converter
User Avatar
No comments yet.