Year 2038 problem

The data type is only capable of representing integers between −(231) and 231 − 1, meaning the latest time that can be properly encoded is 231 − 1 seconds after epoch (03:14:07 UTC on 19 January 2038).

Analogous storage constraints will be reached in 2106, where systems storing Unix time as an unsigned (rather than signed) 32-bit integer will overflow on 7 February 2106 at 06:28:15 UTC.

It may be impractical or, in some cases, impossible to upgrade the software running these systems, ultimately requiring replacement if the 32-bit limitations are to be corrected.

Rather than specifically handling this special case, the initial design simply specified an arbitrary time-out date in the future with a default configuration specifying that requests should time out after a maximum of one billion seconds.

For example, in the C language, any change to the definition of the time_t data type would result in code-compatibility problems in any application in which date and time representations are dependent on the nature of the signed 32-bit time_t integer.

Increasing the size of the time_t type to 64 bits in an existing system would cause incompatible changes to the layout of structures and the binary interface of functions.

Using a signed 64-bit value introduces a new wraparound date that is over twenty times greater than the estimated age of the universe: approximately 292 billion years from now.

[13][14] In particular, Java's and JavaScript's use of 64-bit signed integers to represent absolute timestamps as "milliseconds since 1 January 1970" will work correctly for the next 292 million years.

Other proposals for new time representations provide different precisions, ranges, and sizes (almost always wider than 32 bits), as well as solving other related problems, such as the handling of leap seconds.