Year 2038 Problem
Live countdown to the 32-bit Unix timestamp overflow on January 19, 2038 at 03:14:07 UTC.
Countdown
What happens?
At timestamp 2147483647, a 32-bit signed integer overflows and wraps to -2147483648, which represents December 13, 1901. Systems using 32-bit time_t will jump backwards by 136 years.
The Year 2038 problem (also called Y2038, the Unix Millennium Bug, or the Epochalypse) is a software flaw that causes 32-bit signed Unix timestamps to overflow at 03:14:07 UTC on January 19, 2038. Past that moment, the timestamp wraps around to a large negative number, which most older software interprets as a date in December 1901. This page shows a live countdown to the overflow moment and a hands-on simulator that lets you watch the rollover happen in real time.
What Exactly Breaks on January 19, 2038
Many older C programs, embedded systems, and binary file formats use a 32-bit signed integer to store Unix timestamps. The largest positive value such an integer can hold is 2,147,483,647 - which corresponds to 03:14:07 UTC on January 19, 2038. The next second after that, the value would need to be 2,147,483,648, but a 32-bit signed integer cannot store that. Instead it wraps around to -2,147,483,648, which date libraries interpret as December 13, 1901 at 20:45:52 UTC.
- Modern 64-bit systems are safe. Linux, macOS, and Windows on 64-bit hardware have used 64-bit timestamps for two decades. 64-bit signed integers can represent dates up to the year 292 billion, removing any realistic overflow concern.
- Embedded devices are at risk. Industrial controllers, IoT devices, network equipment, and older firmware often still use 32-bit timestamps to save memory. Some of these will not be patched in time.
- Binary file formats are at risk. Some older log formats, database backups, and protocol packets encode timestamps as 32-bit signed integers regardless of the host architecture. Reading these files past 2038 will require a format migration or a special parser.
- Legacy software is at risk. 32-bit programs running on 64-bit operating systems may still use 32-bit time_t internally. Any code compiled in the 1990s or early 2000s that has not been recompiled with modern toolchains is suspect.
The Countdown Tab
The Countdown tab shows the time remaining until the overflow moment in six units at once: years, months, days, hours, minutes, and seconds. The display updates every second, so the seconds field visibly ticks downward. A progress bar below the countdown shows the percentage of time elapsed since the Unix epoch (January 1, 1970) toward the overflow date - we are currently more than 90% of the way through the 32-bit timestamp range.
The reference moment is January 19, 2038 at exactly 03:14:07 UTC. That displays in your local timezone wherever you are reading this; for example, in New York the overflow happens at 22:14:07 on January 18, 2038. The countdown adjusts automatically for your timezone, but the underlying instant is the same worldwide.
The Simulator Tab
The Simulator tab lets you watch the overflow happen step by step. Click Start and the simulator counts forward through the final seconds before 03:14:07 UTC on January 19, 2038, then continues past the overflow to show what value a 32-bit signed integer would actually hold. The simulator slows down near the moment of overflow so you can see the timestamp jump from 2,147,483,647 to -2,147,483,648 in a single step, then translate that negative value back into the corresponding date in 1901.
This is educational rather than predictive: real systems will not all overflow at the same moment because they store timestamps in different ways. Some 32-bit systems already have unsigned timestamps that overflow in 2106 instead, others use 64-bit storage and never overflow, and some store partial values that overflow earlier than 2038. The simulator demonstrates the canonical case for a 32-bit signed Unix time_t, which is the most common worry.
Why the Bug Exists
Unix was designed in 1969 on hardware with 16-bit and 32-bit registers, and storing timestamps as a 32-bit signed integer counting seconds since 1970 was a reasonable trade-off for a system whose designers expected it to be replaced within a decade or two. The choice persisted as Unix became the foundation of virtually every server operating system, then the foundation of Linux, macOS, and (under the hood) Android. By the time the 2038 issue was widely understood, the format was baked into far too much software to fix everywhere.
The fix is straightforward in principle: switch the time_t typedef from a 32-bit signed integer to a 64-bit signed integer. Modern compilers, languages, and operating systems already do this. The remaining work is identifying every place that still uses the 32-bit form (legacy code, embedded firmware, binary file formats) and migrating them before 2038. The countdown shown above is a reminder of how much time is left to find and fix the last holdouts.
How to Check Your Own System
On Linux or macOS, run date -d @2147483647 (GNU) or date -r 2147483647 (BSD) to see how your system interprets the overflow timestamp. If it returns "January 19, 2038", your local date command is 64-bit safe. To generate that command with the right syntax for your platform, the Linux date command generator handles GNU, macOS, and FreeBSD differences. To inspect any timestamp around the overflow moment, the main timestamp converter handles values up to year 9999 without overflow.
For deeper exploration, the epoch clock shows the live Unix timestamp ticking and lists the same Y2038 milestone in its milestones section alongside other notable epoch landmarks. To project how far in the future the rollover is from a specific moment, use the date difference calculator with your reference date and January 19, 2038.
Frequently Asked Questions
The Year 2038 problem is a software flaw where 32-bit signed Unix timestamps overflow at 03:14:07 UTC on January 19, 2038. The value 2,147,483,647 (the maximum positive 32-bit signed integer) is reached, and the next second causes the value to wrap to -2,147,483,648, which date libraries interpret as December 13, 1901. Modern 64-bit systems are unaffected; the risk lies with legacy code, embedded devices, and binary file formats.
A 32-bit signed Unix timestamp reaches its maximum value (2,147,483,647). The next tick of the clock requires the value 2,147,483,648, which cannot fit in a 32-bit signed integer. Instead the value overflows to -2,147,483,648, the most negative number. Date libraries that interpret signed integers treat that negative value as the corresponding moment 68 years before the epoch: December 13, 1901 at 20:45:52 UTC.
No. 64-bit operating systems (which is virtually every laptop, desktop, server, phone, and tablet sold in the last decade) use 64-bit signed integers for timestamps. A 64-bit signed integer can hold dates up to the year 292 billion, which removes any realistic overflow concern. The remaining risk is embedded devices, legacy software, and binary file formats that still use 32-bit timestamps to save memory.
Conceptually similar: an integer field that was sized for short-term convenience runs out of room and produces nonsense values. The difference is that Y2K affected text-based date fields (two-digit years), while Y2038 affects binary integer timestamps. Y2K was largely averted because the fix was visible in source code; Y2038 is harder because the buggy field is hidden inside binary protocols, firmware, and file formats that are harder to audit.
Some specific data types are. MySQL's TIMESTAMP column is 32-bit and rolls over in 2038; DATETIME is unaffected because it uses a different storage format. PostgreSQL's TIMESTAMP type uses 64-bit microseconds and is safe. SQLite uses double-precision floating point or text. Check your column types now: if you have any TIMESTAMP columns in MySQL, plan a migration to DATETIME before any application starts inserting dates past 2038.
Unsigned 32-bit timestamps can store values up to 4,294,967,295, which corresponds to February 7, 2106 at 06:28:15 UTC. They double the available range but at the cost of losing the ability to represent dates before 1970 (which are stored as negative signed timestamps). Some systems chose unsigned 32-bit as a half-measure fix; the real solution is to use 64-bit signed timestamps everywhere.
On Linux or macOS, run date -d @2147483647 (GNU) or date -r 2147483647 (BSD) and check that the result is January 19, 2038. If it shows that date correctly, your system's date command handles the timestamp without overflow. To test individual applications, schedule a job that runs past 2038 (using a far-future cron expression) or set your test environment's clock to January 2038 and watch for incorrect behavior.
Use 64-bit signed integers for timestamps. Every major operating system, programming language, and database has either already switched or provides a 64-bit option. The remaining work is auditing legacy code, embedded firmware, and binary file formats to find and replace any 32-bit time_t uses. Some 32-bit Linux distributions like Debian and Ubuntu have already migrated to 64-bit time_t on 32-bit architectures.
In two's complement arithmetic, the largest positive 32-bit signed integer is 2,147,483,647 and the most negative is -2,147,483,648. Adding 1 to the maximum wraps around to the minimum because of how the bit pattern is interpreted. The negative timestamp -2,147,483,648 represents a moment 68 years before the Unix epoch, which lands at December 13, 1901 at 20:45:52 UTC. The simulator on this page demonstrates the rollover.
Some already do. Any program that stores a "future date plus a few decades" in a 32-bit timestamp can overflow today if the future date crosses 2038. A 30-year mortgage signed in 2008 reaches its end date in 2038, so software handling that mortgage on a vulnerable system may already misbehave. Insurance policies, scheduled jobs, and TLS certificates with long expiry dates are especially at risk and have been quietly hitting the bug for years.