Skip to main content
Back to Library
postmortem

The 2038 Problem: A 32-Bit Integer, a Decision Made in the 1970s, and the Failure That Is Already Written

5 min read Chapter 29 of 38

The 2038 Problem: A 32-Bit Integer, a Decision Made in the 1970s, and the Failure That Is Already Written in Production Code Running Right Now

The System as Its Engineers Understood It

In the early 1970s, the developers of Unix at Bell Labs needed a way to represent time. They chose the simplest representation that was sufficient for the problem they were solving: a count of seconds since a fixed reference point. The reference point, called the epoch, is January 1, 1970, at 00:00:00 UTC. The count is stored as a signed 32-bit integer. This type, called time_t in C, can represent values from -2,147,483,648 to 2,147,483,647. The positive range, 2,147,483,647 seconds after midnight on January 1, 1970, corresponds to January 19, 2038, at 03:14:07 UTC.

One second after that, the integer overflows. The value wraps from 2,147,483,647 to -2,147,483,648. Systems that interpret this value as a date will compute December 13, 1901. Systems that do not handle the overflow will crash, return errors, or produce undefined behavior.

The Unix developers made this decision with full awareness that the representation had a limit. In the 1970s, the year 2038 was 65 years in the future. The PDP-11 minicomputer they were programming for had a lifespan measured in years, not decades. No software they were writing would still be running in 2038. The decision was rational. A 32-bit integer was sufficient for the foreseeable useful life of the software.

That assumption was wrong, and the Unix developers knew it would be wrong eventually. The assumption was not that time would stop at 2038. The assumption was that the code would be replaced before 2038.

The code was not replaced. It was copied. It was embedded. It was compiled into firmware. It was burned into hardware. The time_t representation spread from Unix to C to POSIX to Linux to every operating system, programming language, library, database, file format, network protocol, and embedded system that adopted the Unix convention of counting seconds since 1970. The 32-bit signed integer representation of time is one of the most widely replicated design decisions in the history of computing.

The Chain

This chapter differs from the others in this book. The failure has not fully occurred. But it has already begun.

Known early failures:

File systems that store modification timestamps as 32-bit integers have already failed when administrators attempted to set dates beyond 2038. The ext3 file system used a 32-bit timestamp and could not represent dates after January 19, 2038. Systems that compute dates 20 years in the future (mortgage calculations, insurance policies, infrastructure maintenance schedules) began encountering the overflow boundary in 2018.

Database systems that store timestamps as 32-bit integers produce incorrect results or errors when computing dates beyond 2038. MySQL’s TIMESTAMP type, stored as a 32-bit integer, cannot represent dates after January 19, 2038. Queries that compute dates beyond this point wrap to 1901 or produce errors, depending on the implementation.

Embedded systems with 32-bit time representations have already triggered failures in testing. A GPS receiver firmware update scheduled for 2036 triggered an overflow during pre-deployment testing because the firmware computed the expiration date by adding an offset to the current time, and the result overflowed.

The current state:

The Linux kernel transitioned to a 64-bit time_t on all architectures, including 32-bit systems, starting with version 5.6 (released in 2020). Applications compiled against the new headers use a 64-bit time_t. Applications compiled against the old headers, or applications that use their own time handling code, remain vulnerable.

The GNU C Library (glibc) supports 64-bit time_t on 32-bit platforms starting with version 2.34. Musl libc has supported 64-bit time_t since version 1.2.0.

64-bit operating systems (which are now the majority of general-purpose computing) use a 64-bit time_t by default. The 64-bit time_t can represent dates until approximately 292 billion years in the future, which is sufficient.

The problem is not in new code running on current operating systems. The problem is in:

  • Embedded systems running 32-bit operating systems with 32-bit firmware that will still be in operation in 2038. Industrial controllers, medical devices, automotive systems, building management systems, SCADA systems, point-of-sale terminals.
  • Databases with 32-bit timestamp columns that store data extending beyond 2038.
  • File formats and network protocols that encode timestamps as 32-bit integers.
  • Legacy applications compiled against old libraries that use 32-bit time_t.

Y2038 timeline showing the 32-bit time_t range, the overflow point, and the categories of affected systems

The diagram shows the time_t value space, with the overflow boundary at January 19, 2038 03:14:07 UTC. Systems that compute future dates (scheduling, certificates, financial instruments) hit the boundary before the clock reaches it. Systems that only use current time hit it precisely at the overflow moment. The diagram illustrates why the 2038 problem is not a single event but a widening failure zone that began in the 2010s and will intensify as the date approaches.