23/09/2022, 02:59 Unix time - Wikipedia

Unix time
In computing, Unix time (also known as Epoch time, Current Unix time
Posix time, seconds since the Epoch, Unix
[1] [2] 1663877928
timestamp or UNIX Epoch time ) is a system for
[3] (2022-09-
describing a point in time. It is the number of seconds 22T20:18:48+00:00)
that have elapsed since the Unix epoch, excluding
leap seconds. The Unix epoch is 00:00:00 UTC on 1 January 1970.

Unix time passed 1 000 000 000

seconds on 2001-09-
09T01:46:40Z. It was celebrated in
Copenhagen, Denmark at a party
held by DKUUG (at 03:46:40 local
time).
Unix time is not a true representation of UTC, because a leap second and the second before it
have the same Unix time (or after it, implementation dependent). Put differently, every day in
Unix time contains exactly 86 400 seconds;[2] no seconds added to or subtracted from the day
as a result of positive or negative leap seconds.
Unix time originally appeared as the system time of Unix, but is now used widely in computing,
for example by filesystems; some Python language library functions handle Unix time.[4]
Definition

Two layers of encoding make up Unix time. The first layer encodes a point in time as a scalar
real number which represents the number of seconds that have passed since 00:00:00 UTC on
Thursday, 1 January 1970.[5] The second layer encodes that number as a sequence of bits or
decimal digits.
As is standard with UTC, this article labels days using the Gregorian calendar and counts times
within each day in hours, minutes, and seconds. Some of the examples also show International
Atomic Time (TAI), another time scheme which uses the same seconds and is displayed in the
same format as UTC, but every day is exactly 86 400 seconds long, gradually losing
synchronization with the Earth's rotation at a rate of roughly one second per year.

Encoding time as a number

https://en.m.wikipedia.org/wiki/Unix_time# 1/15
23/09/2022, 02:59 Unix time - Wikipedia

Unix time is a single signed number that increments every second, which makes it easier for
computers to store and manipulate than conventional date systems. Interpreter programs can
then convert it to a human-readable format.
The Unix epoch is the time 00:00:00 UTC on 1 January 1970.[2] There is a problem with this
definition, in that UTC did not exist in its current form until 1972; this issue is discussed below.
For brevity, the remainder of this section uses ISO 8601 date and time format, in which the
Unix epoch is 1970-01-01T00:00:00Z.
The Unix time number is zero at the Unix epoch and increases by exactly 86 400 per day since
the epoch. Thus 2004-09-16T00:00:00Z, 12 677 days after the epoch, is represented by the
Unix time number 12 677 × 86 400 = 1 095 292 800. This can be extended backwards from
the epoch too, using negative numbers; thus 1957-10-04T00:00:00Z, 4472 days before the
epoch, is represented by the Unix time number −4472 × 86 400 = −386 380 800. This applies
within days as well; the time number at any given time of a day is the number of seconds that
has passed since the midnight starting that day added to the time number of that midnight.
Sometimes, Unix time is mistakenly referred to as Epoch time, because Unix time is based on
an epoch and because of a common misunderstanding that the Unix epoch is the only epoch
(often called "the Epoch"[2]).[6][7][8]

Leap seconds
The above scheme means that on a normal UTC day, which has a duration of 86 400 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:

https://en.m.wikipedia.org/wiki/Unix_time# 2/15
23/09/2022, 02:59 Unix time - Wikipedia

Unix time across midnight into 17 September 2004 (no leap second)
TAI (17 September 2004) UTC (16 to 17 September 2004) Unix time
2004-09-17T00:00:30.75 2004-09-16T23:59:58.75 1 095 379 198.75
2004-09-17T00:00:31.00 2004-09-16T23:59:59.00 1 095 379 199.00
2004-09-17T00:00:31.25 2004-09-16T23:59:59.25 1 095 379 199.25
2004-09-17T00:00:31.50 2004-09-16T23:59:59.50 1 095 379 199.50
2004-09-17T00:00:31.75 2004-09-16T23:59:59.75 1 095 379 199.75
2004-09-17T00:00:32.00 2004-09-17T00:00:00.00 1 095 379 200.00
2004-09-17T00:00:32.25 2004-09-17T00:00:00.25 1 095 379 200.25
2004-09-17T00:00:32.50 2004-09-17T00:00:00.50 1 095 379 200.50
2004-09-17T00:00:32.75 2004-09-17T00:00:00.75 1 095 379 200.75
2004-09-17T00:00:33.00 2004-09-17T00:00:01.00 1 095 379 201.00
2004-09-17T00:00:33.25 2004-09-17T00:00:01.25 1 095 379 201.25
When a leap second occurs, the UTC day is not exactly 86 400 seconds long and the Unix time
number (which always increases by exactly 86 400 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:

https://en.m.wikipedia.org/wiki/Unix_time# 3/15
23/09/2022, 02:59 Unix time - Wikipedia

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 915 148 798.75
1999-01-01T00:00:30.00 1998-12-31T23:59:59.00 915 148 799.00
1999-01-01T00:00:30.25 1998-12-31T23:59:59.25 915 148 799.25
1999-01-01T00:00:30.50 1998-12-31T23:59:59.50 915 148 799.50
1999-01-01T00:00:30.75 1998-12-31T23:59:59.75 915 148 799.75
1999-01-01T00:00:31.00 1998-12-31T23:59:60.00 915 148 800.00
1999-01-01T00:00:31.25 1998-12-31T23:59:60.25 915 148 800.25
1999-01-01T00:00:31.50 1998-12-31T23:59:60.50 915 148 800.50
1999-01-01T00:00:31.75 1998-12-31T23:59:60.75 915 148 800.75
1999-01-01T00:00:32.00 1999-01-01T00:00:00.00 915 148 800.00
1999-01-01T00:00:32.25 1999-01-01T00:00:00.25 915 148 800.25
1999-01-01T00:00:32.50 1999-01-01T00:00:00.50 915 148 800.50
1999-01-01T00:00:32.75 1999-01-01T00:00:00.75 915 148 800.75
1999-01-01T00:00:33.00 1999-01-01T00:00:01.00 915 148 801.00
1999-01-01T00:00:33.25 1999-01-01T00:00:01.25 915 148 801.25
Unix time numbers are repeated in the second immediately following a positive leap second.
The Unix time number 1 483 142 400 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.

https://en.m.wikipedia.org/wiki/Unix_time# 4/15
23/09/2022, 02:59 Unix time - Wikipedia

A Unix time number is easily converted back into a UTC time by taking the quotient and
modulus of the Unix time number, modulo 86 400. 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 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.[9] This is what happens across a
positive leap second:

https://en.m.wikipedia.org/wiki/Unix_time# 5/15
23/09/2022, 02:59 Unix time - Wikipedia

Non-synchronous Mills-style Unix clock

across midnight into 1 January 1999 (positive leap second)
TAI (1 January 1999) UTC (31January
December 1998 to 1
1999) State Unix clock
1999-01- 1998-12-31T23:59:58.75 TIME_INS 915 148 798.75
01T00:00:29.75
1999-01- 1998-12-31T23:59:59.00 TIME_INS 915 148 799.00
01T00:00:30.00
1999-01- 1998-12-31T23:59:59.25 TIME_INS 915 148 799.25
01T00:00:30.25
1999-01- 1998-12-31T23:59:59.50 TIME_INS 915 148 799.50
01T00:00:30.50
1999-01- 1998-12-31T23:59:59.75 TIME_INS 915 148 799.75
01T00:00:30.75
1999-01- 1998-12-31T23:59:60.00 TIME_INS 915 148 800.00
01T00:00:31.00
1999-01- 1998-12-31T23:59:60.25 TIME_OOP 915 148 799.25
01T00:00:31.25
1999-01- 1998-12-31T23:59:60.50 TIME_OOP 915 148 799.50
01T00:00:31.50
1999-01- 1998-12-31T23:59:60.75 TIME_OOP 915 148 799.75
01T00:00:31.75
1999-01- 1999-01-01T00:00:00.00 TIME_OOP 915 148 800.00
01T00:00:32.00
1999-01- 1999-01-01T00:00:00.25 TIME_WAIT 915 148 800.25
01T00:00:32.25
1999-01- 1999-01-01T00:00:00.50 TIME_WAIT 915 148 800.50
01T00:00:32.50
1999-01- 1999-01-01T00:00:00.75 TIME_WAIT 915 148 800.75
01T00:00:32.75
1999-01- 1999-01-01T00:00:01.00 TIME_WAIT 915 148 801.00
01T00:00:33.00
1999-01- 1999-01-01T00:00:01.25 TIME_WAIT 915 148 801.25
01T00:00:33.25
https://en.m.wikipedia.org/wiki/Unix_time# 6/15
23/09/2022, 02:59 Unix time - Wikipedia

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.
TAI-based variant
Another, much rarer, non-conforming variant of Unix time keeping involves encoding TAI rather
than UTC;[10] some Linux systems are configured this way.[11] 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 time stamps 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 TAI-based 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 for TAI-based time was 1970-01-01T00:00:00 TAI rather than 1970-01-
https://en.m.wikipedia.org/wiki/Unix_time# 7/15
23/09/2022, 02:59 Unix time - Wikipedia

01T00:00:10 TAI, was proposed for inclusion in ISO C's time.h , but only the UTC part was
accepted in 2011.[12] A 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 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. Being 32 bits means that it covers a range of about 136
years in total. The minimum representable date is Friday 1901-12-13, and the maximum
representable date is Tuesday 2038-01-19. One second after 03:14:07 UTC 2038-01-19 this
representation will overflow in what is known as the year 2038 problem.
In some newer operating systems, time_t has been widened to 64 bits. This expands the
times representable by approximately 292 billion years in both directions, which is over twenty
times the present age of the universe per direction.
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 ).[13][14] These structures provide a decimal-
based fixed-point data format, which is useful for some applications, and trivial to convert for
others.
https://en.m.wikipedia.org/wiki/Unix_time# 8/15
23/09/2022, 02:59 Unix time - Wikipedia

UTC basis
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.
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 +63 072 000 (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.[15] A likely means to execute this change is to define a new time scale, called
International Time, that initially matches UTC but thereafter has no leap seconds, thus
remaining at a constant offset from TAI. If this happens, it is likely that Unix time will be
prospectively defined in terms of this new time scale, instead of UTC. Uncertainty about
whether this will occur makes prospective Unix time no less predictable than it already is: if
UTC were simply to have no further leap seconds the result would be the same.
History

The earliest versions of Unix time had a 32-bit integer incrementing at a rate of 60 Hz, which
was the rate of the system clock on the hardware of the early Unix systems. The value 60 Hz
still appears in some software interfaces as a result. The epoch also differed from the current
value. The first edition Unix Programmer's Manual dated 3 November 1971 defines the Unix
time as "the time since 00:00:00, 1 January 1971, measured in sixtieths of a second".[16]
The User Manual also commented that "the chronologically-minded user will note that 2**32
sixtieths of a second is only about 2.5 years". Because of this limited range, the epoch was
https://en.m.wikipedia.org/wiki/Unix_time# 9/15
23/09/2022, 02:59 Unix time - Wikipedia

redefined more than once, before the rate was changed to 1 Hz and the epoch was set to its
present value of 1 January 1970 00:00:00 UTC. This yielded a range of about 136 years, half of
it before 1970 and half of it afterwards.
As indicated by the definition quoted above, the Unix time scale was originally intended to be a
simple linear representation of time elapsed since an epoch. However, there was no
consideration of the details of time scales, and it was implicitly assumed that there was a
simple linear time scale already available and agreed upon. The first edition manual's definition
does not even specify which time zone is used. Several later problems, including the
complexity of the present definition, result from Unix time having been defined gradually by
usage rather than fully defined from the outset.
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,
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.
Notable events in Unix time

Unix enthusiasts have a history of holding "time_t parties" (pronounced "time tea parties") to
celebrate significant values of the Unix time number.[17][18] 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,
such as +230 which occurred at 13:37:04 UTC on Saturday, 10 January 2004.
https://en.m.wikipedia.org/wiki/Unix_time# 10/15
23/09/2022, 02:59 Unix time - Wikipedia

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[a] (1973-10-17) within the digits of Unix time (119731017) took place.
At 01:46:40 UTC on Sunday, 9 September 2001, the Unix billennium (Unix time number
1 000 000 000) was celebrated.[19] The name billennium is a portmanteau of billion and
millennium.[20][21] 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. 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.[22]
At 23:31:30 UTC on Friday, 13 February 2009, the decimal representation of Unix time
reached 1 234 567 890 seconds.[23] Google celebrated this with a Google doodle.[24] Parties
and other celebrations were held around the world, among various technical subcultures, to
celebrate the 1 234 567 890th second.[17][25]
At 03:33:20 UTC on Wednesday, 18 May 2033, the Unix time value will equal 2 000 000 000
seconds.
At 09:06:49 UTC on Friday, 16 June 2034, the Unix time value will equal the current year,
month, date and hour (2034061609).
At 06:28:16 UTC on Thursday, 7 February 2036, Network Time Protocol will loop over to the
next epoch, as the 32-bit time stamp value used in NTP (unsigned, but based on 1 January
1900) will overflow. This date is close to the following date because the 136-year range of a
32-bit integer number of seconds is close to twice the 70-year offset between the two
epochs.
At 03:14:08 UTC on Tuesday, 19 January 2038, 32-bit versions of the Unix timestamp will
cease to work, as it will overflow the largest value that can be held in a signed 32-bit number
(7FFFFFFF16 or 2 147 483 647). Before this moment, software using 32-bit time stamps will
need to adopt a new convention for time stamps,[26] and file formats using 32-bit time
stamps will need to be changed to support larger time stamps or a different epoch. If
unchanged, the next second will be incorrectly interpreted as 20:45:52 Friday
13 December 1901 UTC. This is referred to as the Year 2038 problem.
https://en.m.wikipedia.org/wiki/Unix_time# 11/15
23/09/2022, 02:59 Unix time - Wikipedia

At 05:20:00 UTC on Saturday, 24 January 2065, the Unix time value will equal
3 000 000 000 seconds.
At 06:28:15 UTC on Sunday, 7 February 2106, Unix time will reach FFFFFFFF16 or
4 294 967 295 seconds, which, for systems that hold the time on 32-bit unsigned integers,
is the maximum attainable. For some of these systems, the next second will be incorrectly
interpreted as 00:00:00 Thursday 1 January 1970 UTC. Other systems may experience an
overflow error with unpredictable outcomes.
At 15:30:08 UTC on Sunday, 4 December 292 277 026 596,[27][28] Unix time will overflow
the largest value that can be held in a signed 64-bit number. This duration is nearly 22 times
the estimated current age of the universe, which is 1.37 ×1010 (13.7 billion) years.
In literature and calendrics

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".[29]
See also

Epoch (computing)
System time
Notes

a. cited retroactively since ISO 8601 was published in 1988.

References

1. "The Open Group Base Specifications Issue 7, Rationale: Base Definitions, section A.4 General
Concepts" (https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html) . The
Open Group. Retrieved 9 September 2019.
2. "The Open Group Base Specifications Issue 7, section 4.16 Seconds Since the Epoch" (http://pubs.
opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16) . The Open
Group. Retrieved 22 January 2017.
3. Matthew, Neil; Stones, Richard (2008). "The Linux Environment". Beginning Linux Programming.
Indianapolis, Indiana, US: Wiley. p. 148. ISBN 978-0-470-14762-7.
https://en.m.wikipedia.org/wiki/Unix_time# 12/15
23/09/2022, 02:59 Unix time - Wikipedia

4. "time — Time access and conversions" (https://docs.python.org/3/library/time.html) , Python

documentation, retrieved 25 July 2022
5. "Epoch Converter - Unix Timestamp Converter" (https://www.epochconverter.com) . Epoch
Converter. Retrieved 12 January 2020.
6. "Handling timestamps using Format Date in Shortcuts" (https://support.apple.com/guide/shortcuts/
format-date-timestamps-apdfb33b0e17/ios) . Apple Inc. Retrieved 19 June 2019.
7. "RAW date format in CSV exported reports" (https://www-01.ibm.com/support/docview.wss?uid=s
wg21691127) . International Business Machines Corporation (IBM). 22 April 2016. Retrieved
19 June 2019.
8. "TIMESTAMP BY (Azure Stream Analytics)" (https://docs.microsoft.com/en-us/stream-analytics-qu
ery/timestamp-by-azure-stream-analytics) . Microsoft Corporation. Retrieved 19 June 2019.
9. Mills, David L. (12 May 2012). "The NTP Timescale and Leap Seconds" (https://www.eecis.udel.ed
u/~mills/leap.html) . eecis.udel.edu. Retrieved 21 August 2017.
10. "Precision timekeeping" (https://www.iana.org/time-zones/repository/tz-link.html#precision) .
Sources for time zone and daylight saving time data.
11. "Time Scales" (https://support.ntp.org/bin/view/Support/TimeScales) . Network Time Protocol
Wiki. 24 July 2019. Retrieved 12 January 2020.
12. Markus Kuhn. "Modernized API for ISO C" (https://www.cl.cam.ac.uk/~mgk25/time/c/) .
www.cl.cam.ac.uk.
13. "timespec" (https://netbsd.gw.com/cgi-bin/man-cgi?timespec) . NetBSD Manual Pages. 12 April
2011. Retrieved 5 July 2019.
14. "time.h(0P)" (http://man7.org/linux/man-pages/man0/time.h.0p.html) . Linux manual page.
Retrieved 5 July 2019.
15. McCarthy, D. D.; Seidelmann, P. K. (2009). TIME—From Earth Rotation to Atomic Physics.
Weinheim: Wiley–VCH Verlag GmbH & Co. KGaA. p. 232. ISBN 978-3-527-40780-4.
16. Unix Programmer's Manual (https://www.bell-labs.com/usr/dmr/www/pdfs/man22.pdf) (PDF)
(1st ed.). 3 November 1971. Retrieved 28 March 2012. "time returns the time since 00:00:00, 1 Jan.
1971, measured in sixtieths of a second."
17. Tweney, Dylan (12 February 2009). "Unix Lovers to Party Like It's 1234567890" (https://www.wired.
com/gadgetlab/2009/02/unix-lovers-to/) . Wired.
18. "Slashdot | date +%s Turning 1111111111" (https://slashdot.org/story/05/03/17/169200/date-s-turnin
g-1111111111) . 17 March 2005.
19. "Unix time facts & trivia – Unix Time . Info" (https://web.archive.org/web/20171027205157/http://uni
xtime.info/facts.html) . Archived from the original (http://unixtime.info/facts.html) on 27 October
2017.

https://en.m.wikipedia.org/wiki/Unix_time# 13/15
23/09/2022, 02:59 Unix time - Wikipedia

20. "UNIX Approaches Ripe Old Age of One Billion" (https://archive.today/20130413172626/http://www.

electromagnetic.net/press-releases/unixonebln.php) . Electromagnetic.net. Archived from the
original (http://www.electromagnetic.net/press-releases/unixonebln.php) on 13 April 2013.
Retrieved 6 December 2012.
21. Neumann, Peter G. (15 October 2001). "The Risks Digest Volume 21: Issue 69" (http://catless.ncl.a
c.uk/Risks/21.69.html#subj7) . Catless.ncl.ac.uk. Retrieved 6 December 2012.
22. "Technical Problems" (http://linuxmafia.com/wpfaq/problems.html#FITRIX) . linuxmafia.com.
Retrieved 21 August 2017.
23. nixCraft. "Humor: On Feb, Friday 13, 2009 Unix time Will Be 1234567890" (http://www.cyberciti.bi
z/tips/february-13th-unix-time-will-reach-1234567890.html) . Cyberciti.biz. Retrieved
6 December 2012.
24. "Google 1234567890 Logo" (https://www.google.com/logos/unix1234567890.gif) . Google Inc.
Retrieved 28 January 2013.
25. Ahmed, Murad (13 February 2009). "At the third stroke, the Unix time will be 1234567890" (https://
www.thetimes.co.uk/tto/technology/article1859315.ece) . The Times.
26. "Unix Time Stamp.com" (https://www.unixtimestamp.com) . UnixTimeStamp.com. Retrieved
12 January 2020.
27. Spinellis, Diomidis (7 April 2006). Code Quality: The Open Source Perspective (https://books.googl
e.com/books?id=vEN-ckcdtCwC&q=292,277,026,596&pg=PA49) . ISBN 9780321166074.
28. IDRBT Working Paper No. 9 Y2K38 (https://web.archive.org/web/20120513133703/http://www.idrb
t.ac.in/publications/workingpapers/Working%20Paper%20No.%209.pdf) – Ashutosh Saxena and
Sanjay Rawat
29. Mashey, John R. (27 December 2004). "Languages, Levels, Libraries, and Longevity" (https://queu
e.acm.org/detail.cfm?id=1039532) . Queue. 2 (9): 32–38. doi:10.1145/1039511.1039532 (https://d
oi.org/10.1145%2F1039511.1039532) . S2CID 28911378 (https://api.semanticscholar.org/CorpusI
D:28911378) .
External links

Unix Programmer's Manual, first edition (https://www.bell-labs.com/usr/dmr/www/1stEdman.

html)
Personal account of the POSIX decisions (http://www.mail-archive.com/[email protected].
navy.mil/msg00109.html) by Landon Curt Noll
Clewett, James. 2,147,483,647 – The End of Time [Unix] (https://www.youtube.com/watch?v
=QJQ691PTKsA) .
chrono-Compatible Low-Level Date Algorithms (https://howardhinnant.github.io/date_algorit
hms.html) – algorithms to convert between Gregorian and Julian dates and the number of
https://en.m.wikipedia.org/wiki/Unix_time# 14/15
23/09/2022, 02:59 Unix time - Wikipedia

days since the start of Unix time

https://en.m.wikipedia.org/wiki/Unix_time# 15/15