The year 2038 problem explained

Many computer systems store time as a count of seconds since 1 January 1970, UTC. When that count is kept in a signed 32-bit integer, it has a ceiling, and the ceiling arrives at 03:14:07 UTC on 19 January 2038. One second later, affected systems overflow, and the date can jump back to December 1901.

The numbers

• A signed 32-bit integer can hold values up to 2,147,483,647.
• 2,147,483,647 seconds after the Unix epoch is 2038-01-19 03:14:07 UTC.
• Adding one more second wraps the value to −2,147,483,648, which counts backwards from 1970 to 13 December 1901, 20:45:52 UTC.

You can see the boundary yourself: enter 2147483647 in the Timestamp Converter and it shows the last second before the limit. For how Unix time works in general, see Unix timestamps explained.

What is affected

• Embedded devices with long lives and 32-bit processors: industrial controllers, older routers, car systems, medical and building equipment. These are the biggest concern because they are hard to update.
• File formats and protocols that define a 32-bit seconds field, even on modern computers.
• Databases with 32-bit timestamp columns. Some database timestamp types have a range that ends in January 2038.
• Old compiled software built for 32-bit systems.

What is not affected

Modern 64-bit operating systems, languages and libraries store time in 64 bits, which lasts for billions of years. JavaScript dates use a 64-bit floating-point count of milliseconds and are fine. Most phones, laptops and servers in use today will not notice 2038.

Problems can start early

Software that calculates dates in the future hits the limit before 2038. A system computing an expiry date 15 years ahead, a loan schedule or a certificate validity can fail as soon as the result crosses January 2038, and that has already happened in some systems. Anything that works with long future dates should be tested now.

How to check your systems

1. List devices and software expected to still be running in 2038.
2. Check whether timestamps are stored in 32-bit fields, in code, database columns and file formats.
3. Test with dates after the limit: set a test system's clock to 2038-01-19 03:14:00 UTC and watch what happens, or feed future dates into functions that parse and store them.
4. Migrate columns and fields to 64-bit types or to proper date-time types.

Milliseconds versus seconds

Many systems now store milliseconds, which never fit in 32 bits at all and are always 64-bit. If you see a 13-digit timestamp, it is milliseconds. A 10-digit one is seconds, and if it is stored in a 32-bit field, it is the kind to check. The Timestamp Converter detects the unit automatically.

Is it like Y2K?

In spirit, yes: a known limit with a known date, mostly fixable with time and money. The difference is that the riskiest systems are embedded devices that nobody thinks of as computers. As with Y2K, the outcome depends on how much checking happens before the date.