The Year 2038 Problem (Y2K38) Explained
On January 19, 2038 at 03:14:07 UTC, the Unix timestamp 2,147,483,647 — the maximum value of a 32-bit signed integer — will overflow. Here is what that means, which systems are affected, and why most modern code is already safe.
What is the Year 2038 problem?
Unix timestamps are traditionally stored as a signed 32-bit integer counting seconds since January 1, 1970 00:00:00 UTC. The maximum value of a 32-bit signed integer is 2,147,483,647 — which corresponds to January 19, 2038 at 03:14:07 UTC. One second after that moment, the integer overflows to -2,147,483,648. Interpreted as a Unix timestamp, that negative value corresponds to December 13, 1901 — sending affected systems nearly 137 years into the past.
The overflow values
- 2^31 − 1 = 2,147,483,647 (maximum 32-bit signed integer)
- 2,147,483,647 as a date = January 19, 2038 03:14:07 UTC
- 2,147,483,647 + 1 overflows to −2,147,483,648 (the most negative 32-bit value)
- −2,147,483,648 as a date = December 13, 1901 20:45:52 UTC
Which systems are at risk?
The problem affects systems that store timestamps as 32-bit signed integers:
- Embedded systems and microcontrollers with 32-bit time_t
- Legacy C and C++ code compiled for 32-bit targets using time_t or int for timestamps
- Old Linux kernels (before 5.6) on 32-bit hardware still in production
- MySQL TIMESTAMP columns — limited to 2038-01-19; use DATETIME instead
- Some network protocols and file formats that encode timestamps as 32-bit values
- Firmware in industrial control systems and IoT devices with decade-long lifespans
Which systems are safe?
Most modern code and infrastructure is already unaffected:
- Any 64-bit OS — Linux (glibc 2.34+ also fixes 32-bit hardware), macOS, Windows
- Python — timestamps use 64-bit floats, safe well past the year 292 million
- JavaScript — Date uses 64-bit IEEE 754 floats, safe to year 275,760
- Go and Rust — use int64 for time internally, safe for billions of years
- Java — java.time.Instant uses long (64-bit), safe to year ~292 million
- PostgreSQL TIMESTAMP — stores dates beyond 2038 correctly
- MySQL DATETIME — range 1000-01-01 to 9999-12-31, unaffected
Year 2038 problem FAQ
- What is the Year 2038 problem?
- The Year 2038 problem (Y2K38) is a bug where systems using 32-bit signed integers to store Unix timestamps will overflow on January 19, 2038 at 03:14:07 UTC. The maximum value of a 32-bit signed integer is 2,147,483,647. One second later, the integer wraps to -2,147,483,648, which corresponds to December 13, 1901.
- What is the Unix timestamp for January 19, 2038?
- The Unix timestamp for January 19, 2038 at 03:14:07 UTC is 2,147,483,647 — the maximum value of a 32-bit signed integer (2^31 - 1). This is the exact moment the Year 2038 overflow occurs on 32-bit systems.
- Is Y2K38 the same as Y2K?
- No. Y2K (Year 2000 problem) was caused by programs storing years as 2-digit numbers. Y2K38 is caused by storing Unix timestamps as 32-bit signed integers that overflow in 2038. Different root causes, different affected systems.
- Will the internet break in 2038?
- Probably not significantly. Most internet infrastructure has already migrated to 64-bit systems. The risk is concentrated in embedded systems, legacy IoT devices, and software that has not been updated in decades. Modern operating systems, programming languages, and databases are already safe.