What Is the Year 2038 Problem?

At 03:14:07 UTC on Tuesday, January 19, 2038, a thirty-two-bit counter that older computers use to tell time runs out of room. That is what the year 2038 problem is. One second later, machines still relying on that counter believe the date is Friday, December 13, 1901.

Your laptop and phone are almost certainly fine. The thermostat bolted to a boiler room wall in 2011 is another story, and the rest of this page covers which is which, in detail.

Where the number comes from

Unix systems count time as seconds elapsed since midnight UTC on January 1, 1970. No months, no time zones, one plain number ticking upward. It's a genuinely elegant scheme, and nearly everything digital adopted it.

The catch is the container. For decades that count was stored in a signed 32-bit integer, a type usually called time_t, and a signed 32-bit integer tops out at 2,147,483,647. Signed, because negative values let the same scheme describe dates before 1970.

Count 2,147,483,647 seconds forward from 1970 and you land on 03:14:07 UTC, January 19, 2038.

You can watch the edge yourself. Paste 2147483647 into the Unix timestamp converter and there it is, the last second a 32-bit clock can name.

What happens one second later

Binary odometers don't show an error when they roll over. The counter ticks from its largest positive value straight to its most negative one, −2,147,483,648, and software dutifully interprets that as a date. December 13, 1901, 20:45:52 UTC.

What a machine does with a sudden trip to 1901 varies, and none of the options are good.

• Certificate checks fail, since every certificate ever issued is now "not yet valid."
• Scheduled jobs go quiet or fire wildly. A cron daemon that thinks 137 years of appointments are in the future has nothing to do.
• Age and interval math turns negative. Files modified "in the future," sessions that expire before they start, logs that sort into nonsense.
• Some systems just crash, which by comparison is the honest response.

It is already happening

The failure arrives early wherever software computes future dates, and that's been true for years.

Back in 2006, AOLserver installations started crashing because a configuration meant "never time out" was implemented as "time out one billion seconds from now," which crossed the 2038 line. Thirty-year mortgages did the same math earlier still. A pension system calculating a payout date in 2040 hits the wall today, no waiting required.

I rolled a spare Raspberry Pi forward to test this for myself last winter, an old 32-bit OS image I had lying around from 2016. Set the clock to 03:13 on January 19, 2038, watched the minute tick over, and the log timestamps snapped to December 1901 while cron simply stopped, no error, nothing. The eeriest part was how quiet it was.. A modern 64-bit image on the same board sailed through untouched.

Loads from YouTube on play

Y2K's quieter, harder sibling

The comparison everyone reaches for is the millennium bug, and the mechanics really are cousins.

Y2K passed gently because thousands of maintainers spent years on unglamorous remediation, and their reward was two decades of jokes about how it "turned out to be nothing." That reading gets the lesson exactly backwards. Quiet, faithful fixing is why nothing happened, and 2038 needs the same kind of work with less of it visible, because you can't grep a router's firmware from the outside.

In some ways 2038 is the harder assignment. A two-digit year sat in COBOL source someone could read. A 32-bit time_t is baked into devices whose manufacturers dissolved in 2019.

What's already fixed

Most of the modern world, genuinely.

• Native applications and data paths using 64-bit time don't overflow for roughly 292 billion years. A 64-bit operating system is not proof by itself because it may still run a legacy 32-bit binary or read a format with a narrower timestamp.
• The Linux kernel grew full 64-bit time support for 32-bit hardware in version 5.6, back in 2020, and Debian rebuilt its 32-bit ARM ports around 64-bit time for the trixie release. OpenBSD made the jump in 2014, NetBSD earlier still.
• Filesystems got extensions. ext4 access, modification, and change times reach 2446 only when the inode is larger than 128 bytes and contains the extra timestamp fields; legacy 128-byte inodes stop in 2038. XFS filesystems with the bigtime feature enabled go to 2486, while volumes created without it keep the older range until they are upgraded.
• JavaScript's Date and Python's datetime representation are not inherently limited to signed 32-bit Unix time. But Python methods such as datetime.fromtimestamp() can still raise an error when the platform C library's localtime() or gmtime() stops at 2038.

What's still exposed

The long tail, and it is long.

Embedded devices. Routers, smart meters, industrial controllers, building HVAC, medical equipment. A 32-bit processor alone does not make one vulnerable; the exposed cases are those whose firmware, APIs, protocols, or stored data narrow time to a signed 32-bit value. These devices tend to outlive their support contracts. A car assembled in 2024 can still be on the road in 2038, so its timestamp representation deserves checking long before then.

MySQL's TIMESTAMP column. It ends at exactly 03:14:07 on January 19, 2038, and inserting anything later fails. The fix has existed forever, use DATETIME instead. MariaDB extended TIMESTAMP to 2106 on 64-bit builds beginning with Community Server 11.5; 32-bit builds retain the 2038 maximum. Plenty of production schemas haven't heard the news.

32-bit binaries nobody can rebuild. A statically compiled program from 2009 whose source is gone remains vulnerable even on a patched 64-bit kernel. Depending on its APIs and error handling, a post-2038 value may return EOVERFLOW, wrap to 1901, crash, or fail some other way. Test the actual binary rather than assuming one outcome.

Some protocols meet a different 32-bit ceiling. NFSv3 timestamps use unsigned 32-bit seconds on the wire, which reaches 2106. An NFS client or server can still fail in 2038 if its implementation converts that value through a signed 32-bit time_t, but that limit is in the implementation rather than the NFSv3 field.

How to check your own systems

For a normal person the honest answer is that there's little to do. Keep firmware updated, and be mildly suspicious of any internet-connected device old enough to vote.

For anyone who runs systems, twenty minutes of testing beats a decade of wondering.

1. On Linux, run date -u -d @2147483648. On macOS, use date -u -r 2147483648. A supporting utility prints 03:14:08 UTC on January 19, 2038; an error or a date in 1901 signals trouble. Passing this check confirms the date utility and its underlying libraries, not every application on the machine.
2. Roll a test VM's clock to 03:13 UTC, January 19, 2038, and watch what your application does across the boundary. faketime does this without touching the real clock.
3. Search schemas for TIMESTAMP columns and check any stored epoch values with the timestamp converter. While you're there, 13-digit values are milliseconds and nearly always already 64-bit, so panic is usually reserved for the 10-digit ones.
4. Check the exp claim on long-lived tokens with the JWT decoder. The JWT standard defines exp as a NumericDate and does not impose a 32-bit limit. Risk appears when a verifier narrows that number through signed 32-bit storage or a legacy time API; it may reject, overflow, or misread a post-2038 expiry.

The numbers worth keeping

Wikipedia's Year 2038 problem article keeps a running list of affected software if you need the exhaustive version.

FAQs

Will my computer stop working in 2038? If it's a 64-bit machine running an OS from the last decade, no. The risk lives in old 32-bit devices and in software carrying its own 32-bit time handling.

What time does it happen where I live? The rollover is one worldwide instant, 03:14:08 UTC on January 19. That's 10:14 PM on the 18th in New York, 7:14 PM in Los Angeles. Convert it for your zone with the timestamp converter.

Wasn't Y2K a hoax? Why is this different? Y2K was real and got fixed, which is different from fake. 2038 has the same shape with a harder-to-reach fix, since much of it sits in firmware rather than source code.

Is there also a 2036 problem? There is. NTP, the protocol computers use to sync clocks, has its own 32-bit counter dating from 1900, and its era rolls over on February 7, 2036, two years earlier. Modern NTP implementations handle it, elderly ones may not.

What should developers use instead of 32-bit time_t? A 64-bit time type, on every platform, with no exceptions for "temporary" code. In my experience temporary code is the code that's still running in 2038.