Guide
On January 19, 2038, at 03:14:07 UTC, a huge number of older systems that store time as a 32-bit signed integer will run out of room to count. Here's exactly what happens, who's affected, and what's being done about it.
Live
This is a real countdown, ticking in your browser right now, to 2038-01-19T03:14:07 UTC.
Unix time counts seconds since January 1, 1970. Many systems written decades ago — and plenty still in use today — store that count in a signed 32-bit integer. A signed 32-bit integer can only hold values up to 2,147,483,647. Add that many seconds to the 1970 epoch and you land exactly on January 19, 2038, at 03:14:07 UTC.
One second later, the counter would need to become 2,147,483,648 — which doesn't fit. Instead, it overflows and wraps around to a large negative number, which most systems then interpret as a date back in December 1901. Any code that depends on time moving forward — session expiry, scheduled jobs, certificate validity, file timestamps, financial calculations — can behave unpredictably the moment that happens.
The underlying shape of the problem is similar — a fixed-width field for representing dates runs out of space — but the cause is different. Y2K was about two-digit year fields in human-facing date formats. The 2038 problem is about a 32-bit binary integer used internally by operating systems and programming languages, largely invisible to the people using the software until it breaks.
Most modern 64-bit operating systems and up-to-date programming language runtimes already use a 64-bit time value, which pushes the overflow date out to roughly the year 292 billion — effectively never. The real risk sits in three places:
The main fix is straightforward in principle: move to a 64-bit time representation. Most major operating systems (including 64-bit Linux, modern Windows, and current versions of iOS/Android) already store time in 64 bits internally. The harder, slower work is auditing older embedded systems, industrial equipment, and legacy databases that are difficult to patch or physically hard to reach — similar in spirit to the long tail of Y2K remediation work that took years, not the single date itself.
If you work with timestamps, it's worth checking: does your database column, file format, or third-party library use a 32-bit signed integer for time anywhere in the stack? If so, plan a migration to a 64-bit type well before 2038 — ideally now, while it's routine maintenance rather than an emergency. You can use the timestamp converter on this site to sanity-check how a given system represents dates near the boundary.