Editing Unix time (section)

== History ==
{{More citations needed section|date=September 2019}}
The earliest versions of Unix time had a 32-bit integer incrementing at a rate of 60&nbsp;[[Hertz|Hz]], which was the rate of the system clock on the hardware of the early Unix systems. Timestamps stored this way could only represent a range of a little over two and a quarter years. The epoch being counted from was changed with Unix releases to prevent overflow, with midnight on 1&nbsp;January 1971 and 1&nbsp;January 1972 both being used as epochs during Unix's early development. Early definitions of Unix time also lacked timezones.<ref>{{cite book|title=Unix Programmer's Manual|edition=1st|url=https://www.bell-labs.com/usr/dmr/www/pdfs/man22.pdf|quote="''time'' returns the time since 00:00:00, Jan. 1, 1971, measured in sixtieths of a second."|date=3 November 1971|access-date=28 March 2012|archive-date=5 March 2022|archive-url=https://web.archive.org/web/20220305094724/https://www.bell-labs.com/usr/dmr/www/pdfs/man22.pdf|url-status=live}}</ref><ref>{{cite book|title=Unix Programmer's Manual|edition=3rd|url=http://bitsavers.org/pdf/att/unix/3rd_Edition/UNIX_Programmers_Manual_Third_Edition_Feb73.pdf|quote="''time'' returns the time since 00:00:00, Jan. 1, 1972, measured in sixtieths of a second...The time is stored in 32 bits. This guarantees a crisis every 2.26 years."|date=15 March 1972|access-date=11 February 2023|archive-date=12 February 2023|archive-url=https://web.archive.org/web/20230212065854/http://bitsavers.org/pdf/att/unix/3rd_Edition/UNIX_Programmers_Manual_Third_Edition_Feb73.pdf|url-status=live}}</ref>

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

When [[POSIX#POSIX.1|POSIX.1]] was written, the question arose of how to precisely define <code>time_t</code> in the face of leap seconds. The POSIX committee considered whether Unix time should remain, as intended, a linear count of seconds since the epoch, at the expense of complexity in conversions with civil time or a representation of civil time, at the expense of inconsistency around leap seconds. Computer clocks of the era were not sufficiently precisely set to form a precedent one way or the other.

The POSIX committee was swayed by arguments against complexity in the library functions,{{Citation needed|date=January 2012}} and firmly defined the Unix time in a simple manner in terms of the elements of UTC time. This definition was so simple that it did not even encompass the entire [[leap year]] rule of the Gregorian calendar, and would make 2100 a leap year.

The 2001 edition of POSIX.1 rectified the faulty leap year rule in the definition of Unix time, but retained the essential definition of Unix time as an encoding of UTC rather than a linear time scale. Since the mid-1990s, computer clocks have been routinely set with sufficient precision for this to matter, and they have most commonly been set using the UTC-based definition of Unix time. This has resulted in considerable complexity in Unix implementations, and in the [[Network Time Protocol]], to execute steps in the Unix time number whenever leap seconds occur.{{Citation needed|date=May 2020}}