The Year 2038 Problem
Why 32-bit Unix timestamps run out in 2038, what breaks, and how to check your own systems.
What happens in 2038
Many older systems store Unix time in a signed 32-bit integer. The largest value such an integer can hold is 2,147,483,647, which is 03:14:07 UTC on 19 January 2038. One second later the value wraps around to -2,147,483,648, which older software reads as 20:45:52 UTC on 13 December 1901.
You can check both moments by entering 2147483647 and -2147483648 in the epoch converter.
What is affected
Software compiled with a 32-bit time_t, embedded devices and firmware that will still be running in 2038, file formats with 32-bit time fields, and some database column types are the main risks. For example, MySQL's TIMESTAMP column type is documented as ending at 2038-01-19 03:14:07 UTC, while DATETIME covers a much longer range.
Most modern 64-bit operating systems and current language runtimes already use 64-bit time values, which cover hundreds of billions of years. The risk is concentrated in long-lived devices, old binaries and data formats.
What to do about it
Store timestamps in 64-bit integers or in date-time column types with a wide range. Audit any place where a timestamp is cast to a 32-bit integer, serialised into a binary format, or accepted from a device. Test your systems with dates after 2038 and with the boundary values above, and plan upgrades for hardware that cannot be updated.