There is no universal solution for the Year 2038 problem. 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. For example, changing time_t to an unsigned 32-bit integer, which would extend the range to 2106 (specifically, 06:28:15 UTC on Sunday, 7 February 2106), would adversely affect programs that store, retrieve, or manipulate dates prior to 1970, as such dates are represented by negative numbers. 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.
Most operating systems designed to run on 64-bit
hardware already use signed 64-bit time_t integers. 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. The ability to make
computations on dates is limited by the fact that tm_year uses a signed 32-bit integer value starting at 1900 for the year. This limits the year to a maximum of 2,147,485,547 (2,147,483,647 + 1900).
[12]
FreeBSD uses 64-bit time_t for all 32-bit and 64-bit architectures except 32-bit i386, which uses signed 32-bit time_t instead.
[13]
Starting with
NetBSD version 6.0 (released in October 2012), the NetBSD operating system uses a 64-bit time_t for both 32-bit and 64-bit architectures. Applications that were compiled for an older NetBSD release with 32-bit time_t are supported via a binary compatibility layer, but such older applications will still suffer from the Year 2038 problem.
[14]
OpenBSD since version 5.5, released in May 2014, also uses a 64-bit time_t for both 32-bit and 64-bit architectures. In contrast to
NetBSD, there is no binary compatibility layer. Therefore, applications expecting a 32-bit time_t and applications using anything different from time_t to store time values may break.
[15]
Linux originally used a 64-bit time_t for 64-bit architectures only; the pure 32-bit
ABI was not changed due to backward compatibility.
[16] Starting with version 5.6, 64-bit time_t is supported on 32-bit architectures, too. This was done primarily for the sake of
embedded Linux systems.
[17]
The
x32 ABI for Linux (which defines an environment for programs with 32-bit addresses but running the processor in 64-bit mode) uses a 64-bit time_t. Since it was a new environment, there was no need for special compatibility precautions.
[16]
While the native APIs of
OpenVMS can support timestamps up to the 31st of July 31086,
[18] the C runtime library (CRTL) uses 32-bit integers for time_t.
[19] As part of Y2K compliance work that was carried out in 1998, the CRTL was modified to use unsigned 32-bit integers to represent time; extending the range of time_t up to the 7th of February 2106.
[20]
Network File System version 4 has defined its time fields as struct nfstime4 {int64_t seconds; uint32_t nseconds;} since December 2000.
[21] Values greater than zero for the seconds field denote dates after the 0-hour, January 1, 1970. Values less than zero for the seconds field denote dates before the 0-hour, January 1, 1970. In both cases, the nseconds (nanoseconds) field is to be added to the seconds field for the final time representation.
Alternative proposals have been made (some of which are already in use), such as storing either
milliseconds or
microseconds since an epoch (typically either 1 January 1970 or 1 January 2000) in a signed 64-bit integer, providing a minimum range of 300,000 years at microsecond resolution.
[22][23] In particular, Java's use of 64-bit long integers everywhere to represent time 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. In particular, TAI64
[24] is an implementation of the
International Atomic Time (TAI) standard, the current international real-time standard for defining a second and frame of reference.
