What causes the problem?
Unix timestamps are stored as signed 32-bit integers on many older systems. A signed 32-bit integer can store values from -2,147,483,648 to 2,147,483,647. Once the timestamp reaches 2,147,483,647 — representing January 19, 2038 at 03:14:07 UTC — the next increment causes an integer overflow, wrapping the value to the most negative number.
This is not a display issue like Y2K. It is a hard binary overflow that can corrupt data, crash software, or cause systems to behave as if the date is December 1901.
What systems are at risk?
🔌
32-bit Linux kernels
HIGH RISK🗃
Legacy databases (INT 32)
HIGH RISK📱
Embedded / IoT devices
HIGH RISK💻
64-bit Linux / macOS
SAFE🖥
Windows (64-bit)
SAFE📈
Old SCADA systems
MEDIUMFrequently Asked Questions
When exactly does the overflow happen? +
At Unix timestamp 2147483647 — January 19, 2038 at 03:14:07 UTC. The very next second the 32-bit integer wraps to -2147483648, equivalent to December 13, 1901.
How do I fix the Year 2038 problem? +
Migrate all timestamp storage from 32-bit INT to 64-bit BIGINT. In MySQL/PostgreSQL use BIGINT instead of INT for timestamp columns. Ensure your application layer uses 64-bit time_t. Most modern 64-bit operating systems already handle this correctly.
Is this the same as Y2K? +
Similar in concept but technically different. Y2K was a display/parsing issue with 2-digit years. Y2K38 is a hard binary integer overflow. Y2K was mostly fixed by software updates. Y2K38 requires hardware or data type changes on affected 32-bit systems.
Does this affect modern computers? +
Most modern 64-bit computers and operating systems are not affected. The main risks are 32-bit embedded systems, IoT devices with long lifespans, legacy databases with INT(11) timestamp columns, and old industrial control systems.
Convert any Unix timestamp instantly
Use our free Unix Timestamp Converter to convert dates, do date math, and get code snippets.
→ Open Timestamp Converter