Unix epoch

The Unix epoch is the representation of points in time as the number of non-leap seconds since 00:00:00 UTC on January 1 1970, introduced by the Unix operating system, standardised in POSIX, and later adopted by the Java programming language and JavaScript. Because many computers today store the number of seconds as a 32-bit signed integer, the Unix epoch is often said to last 2³¹ seconds, thus “ending” at 03:14:07 Tuesday, January 19, 2038 (UTC).

Table of contents

1 Storage formats for Unix times 2 Effects of the 2038 rollover 3 Leap seconds in the Unix epoch 4 Trivia

Storage formats for Unix times

In POSIX conforming systems, the type time_t is often used to represent times. It is an arithmetic type in the C programming language. There is no requirement that time_t be a 32-bit quantity (it could be a 64-bit integer or a floating point in double format), but most systems define time_t as a signed 32-bit integer, and many application programs may assume it, or may store values in a 32-bit type. A signed 32-bit integer type can represent numbers ranging from -2³¹ to 2³¹ - 1, that is, -2147483648 to 2147483647. In this format, time_t will run out of positive integers 2³¹-1 seconds (that is 24855 days, 3 hours, 14 minutes and 7 seconds) after the Epoch, in the year 2038, and thus cannot represent times beyond that point.

Effects of the 2038 rollover

Programs which must handle times beyond the rollover data will need to be changed to accommodate a shift from 32-bit to 64-bit representation, not unlike the Year 2000 problem. Adapting existing programs may be as easy as re-compiling them with header files that declare time_t as a 64-bit integer, but other programs make deep assumptions as to the nature of time_t. Also, the source code to some software packages may have been lost by then, in which case programmers might have to reverse engineer the software to change its date behavior. In fact, some claim that the expiration of the Unix epoch timeframe may cause more damage than was predicted for the Y2K bug.

Leap seconds in the Unix epoch

The necessity of leap seconds, means that it is not possible in general to say how many SI seconds elapse between two specified times in the Unix epoch. This is because it is not possible to predict when a leap second will be required more than a few years in advance. In practice this has very rarely posed any significant problem.

However, the exact time in civil time (UTC) when the rollover will occur cannot be determined beforehand because of leap seconds. The 03:14:07, January 19, 2038 time is the time of the rollover if leap seconds are ignored. Thus, the actual time of the rollover in the real world where leap seconds are observed would most probably be different from the Unix time.

There is an accuracy dispute over the above paragraph. Please see the talk page for details.

Trivia

One thousand million seconds after the start of the Unix epoch was 01:46:40 UTC on September 9, 2001, a moment known as the Unix billennium.

2³⁰ (1073741824) seconds from the start of the Unix epoch was 13:37:04 UTC on January 10, 2004. This was the first time value to require 31 bits of storage. Curiously, the digits at this time spell “1337”

In Vernor Vinge's novel A Deepness in the Sky, it is revealed that the Qeng Ho interstellar traders use the Unix epoch as their timekeeping system.