← Back to blog

The Year 2038 Problem Is Already Breaking Things

Published October 19, 2026 · 9 min read

The year 2038 problem has a date on it: 03:14:07 UTC on January 19, 2038. That's about eleven years from now, which sounds like plenty of time to ignore it.

Here's the part most explainers skip. The bug doesn't wait for 2038. It goes off the moment any program does math on a date past 2038, and programs do that all the time. Cookie expirations. Certificate lifetimes. Loan schedules. "Never expire" timeouts. The bug first took down production servers in 2006, and it's been showing up ever since.

By the end of this post you'll know why the limit exists, four real incidents where it already bit, where it likely hides in your own stack, and a five-minute check you can run with a free timestamp converter.

What the year 2038 problem actually is

A lot of software stores time as a single number: the seconds since midnight UTC on January 1, 1970. That's Unix time, and the starting point is called the epoch. Right now (mid-October 2026) the number is a little under 1.8 billion.

The trouble is the box that number lives in. For decades, the standard choice was a signed 32-bit integer. Signed means it holds negatives too, so the biggest value it can store is 2,147,483,647. Add that many seconds to 1970 and you land on 03:14:07 UTC, January 19, 2038. (If you're on the US West Coast, that's 7:14:07 PM Pacific on January 18.)

One second later, the counter overflows. The sign bit flips and the number becomes −2,147,483,648, which software reads as 20:45:52 UTC on December 13, 1901. Your server doesn't crash into the future. It falls 136 years into the past. That's all laid out on Wikipedia's Year 2038 problem page, which is unusually well sourced for this one.

Y2K happened because people saved space with two decimal digits for the year. Y2038 is the binary cousin: a fixed-width box that runs out of room.

The real deadline is "now plus however far ahead you look"

This is the counterintuitive part, and the reason the bug is already here.

Software rarely just stores today. It computes later. "This session expires in 30 days." "This certificate is good for 20 years." "Retry until this deadline." Each of those takes the current timestamp and adds to it. If the sum passes 2,147,483,647, a 32-bit system overflows today, not in 2038.

So every system has its own personal 2038:

• A program that looks 1 billion seconds ahead (about 31.7 years) broke in May 2006.
• One that looks 500 million seconds ahead (about 15.8 years) broke in March 2022.
• As of this month, anything that looks more than about 11 years and 3 months ahead is already past the line.

That last one should get your attention. Fifteen-year mortgages, 12-year warranties, long-lived signing certificates, and "remember me for 20 years" cookies are all over that line right now. Every day, the window shrinks by one more day, and more ordinary code starts running into it.

Four times the year 2038 problem already hit

None of these are hypotheticals. Each one is documented, and each follows the same pattern: some future date crossed the line.

2006: AOLserver's "never time out" timeout

AOLserver, AOL's open-source web server, needed a way to say a database request should never time out. Rather than special-casing "never," the default config set the timeout to one billion seconds in the future.

One billion seconds before the 2038 cutoff is 01:27:28 UTC on May 13, 2006. After that moment, "now plus a billion seconds" overflowed into the past. The server decided every request had already timed out and started failing. Operators fixed it by editing the config to a smaller number. The incident is recorded in the Wikipedia article's "Early problems" section, which cites the original 2006 reports.

The lesson: "a really big number" is not the same as "infinity."

2010: The VPN certificate that expired in 1910

In late 2010, a retailer's VPN hardware stopped working over a weekend. The support engineer who traced it later told the story to The Register. The VPN boxes couldn't validate certificates because the revocation list had grown too big to download, which made no sense for a lightly used internal certificate authority.

The certificate authority's own certificate claimed it wasn't valid before 2037 and wasn't valid after 1910. In other words, it was never valid. So the CA woke up, decided its certificate had expired, and revoked and reissued every certificate it had signed. Then it did it again one second later. And again.

The root cause wasn't the CA. A time server had turned a tiny negative clock correction into an enormous positive one, which threw the clock forward toward 2037. Add a normal certificate lifetime to that and you've crossed 2038, wrapped to the early 1900s, and created a certificate from the past. The APNIC blog's write-up on the incident is worth reading if you run your own time infrastructure.

The lesson: your clock doesn't have to reach 2038 on its own. One bad jump will do it.

2022: Microsoft Exchange's New Year's Day outage

On January 1, 2022, Exchange Server's malware-filtering engine stopped working around the world. The engine stored update version numbers in a format like YYMMDDNNNN and squeezed them into a signed 32-bit integer.

The first update of 2022 was 2201010001. The 32-bit limit is 2,147,483,647. The version number was bigger, so the engine logged Can't convert "2201010001" to long and crashed, and mail sat stuck in queues on Exchange 2016 and 2019. Some admins turned off malware scanning just to get email moving. Microsoft's own post-mortem shipped a fix script the next day, and Neowin dubbed it the "Y2K22" bug.

This one isn't strictly about timestamps, and that's why it matters. The limit is a property of the box, and people put all kinds of date-shaped numbers into 32-bit boxes.

2022: Oracle's 15-year cookie

In Oracle Access Manager 10.1.4.3 for Windows, one component set a preferences cookie to expire 500,000,000 seconds out, roughly 15 years and 10 months. Starting around 02:20:48 UTC on March 17, 2022, that expiry date landed after January 2038, the date conversion failed, and certain searches threw exceptions. Oracle shipped a patch in April 2022. It's in the same Wikipedia section, citing Oracle's community forum.

The lesson: arbitrary "far future" constants are tiny time bombs, and you can calculate exactly when each one goes off.

Where the year 2038 problem hides in 2026

The good news: most of the obvious places are fixed. Linux added 64-bit time support for 32-bit architectures in kernel 5.6 in 2020. The GNU C Library added an opt-in 64-bit time mode in version 2.34 in 2021. JavaScript's Date counts milliseconds in a double-precision number and is good out to the year 275,760, per MDN's Date reference. A signed 64-bit counter won't overflow for about 292 billion years.

The bad news: "the platform is fixed" doesn't mean your data is. These spots are still worth a look.

Database columns that look modern

This one surprises people. In MySQL, the TIMESTAMP column type still tops out at 2038-01-19 03:14:07 UTC, even on current versions. The MySQL reference manual says so directly. DATETIME goes to the year 9999. If you've got an expires_at TIMESTAMP column and your app writes a date 15 years out, you've got a problem today, not in 2038.

MySQL 8.0.28 (January 2022) did fix the UNIX_TIMESTAMP() and FROM_UNIXTIME() functions to handle 64-bit values on 64-bit platforms. Older versions return 0 for dates past the limit. Check which version you're on and which column types you picked years ago.

Integer fields that "just hold a timestamp"

Any INT column, struct field, or protocol message defined as 32 bits that stores epoch seconds has the same ceiling, no matter how new the language around it is. A 64-bit server reading a 32-bit field from a file, an API, or an old schema inherits the old limit.

Embedded devices and old firmware

Routers, cameras, industrial controllers, and cars run for decades and rarely get updates. Wikipedia's list of affected systems includes older 32-bit Android and iOS devices and file systems like ext3 that store 32-bit inode times. If a device can't be updated, the realistic fix is replacing it before it matters.

Hard-coded "forever" values

Search your code for big round numbers: 999999999, 1000000000, 2147483647, or "expire in 100 years" constants. Each one is a future date. Some of them have already crossed the line.

A 5-minute check you can run today

You don't need a code audit to get a feel for your exposure. You need a timestamp converter and a list of the furthest-out dates your systems handle. CyberScryb's free Epoch / Unix Timestamp Converter does both directions and runs in your browser.

1. See the edge. Paste 2147483647 into the timestamp-to-date box. You'll get January 19, 2038, 03:14:07 UTC. That's the ceiling every 32-bit field shares.
2. Paste what's in your data. Grab a far-future value from your database, a cookie, or an API response, and convert it. If it shows a date in 1901 or 1902, or a negative number, you've found an overflow that already happened.
3. Go the other way. Enter the furthest date your product promises, like a loan's last payment, a warranty end, or a certificate expiry, and convert it to a timestamp. If the result is bigger than 2,147,483,647, any 32-bit field that touches it will break.
4. Watch for milliseconds. A 13-digit number is milliseconds, not seconds. Mixing them up is its own classic bug, and the converter page explains how to spot it.
5. Write down your horizon. Take today's timestamp, subtract it from 2,147,483,647, and you've got the seconds left before "now plus your lookahead" crosses the line. In mid-October 2026, that's roughly 355 million seconds, or about 11 years and 3 months.

If every far-future value converts cleanly and every storage type is 64-bit or DATETIME, you're in decent shape. If not, you now know exactly which field to fix first.

How to fix it once you find it

The fixes are boring, which is the best kind.

• Widen the box. Move epoch-seconds fields to 64-bit integers. In MySQL, move far-future columns from TIMESTAMP to DATETIME and store UTC on purpose.
• Recompile 32-bit C code with 64-bit time. On glibc 2.34 and later, build with _TIME_BITS=64 (which also needs _FILE_OFFSET_BITS=64), and test anything that writes times to disk or the network.
• Replace "forever" with a real flag. If something should never expire, store null or a boolean and handle it. Don't fake it with a huge number.
• Test with the clock set forward. Run your test suite with a fake clock in 2039. Bugs that hide for eleven years show up in eleven seconds.
• Inventory the hardware. List the embedded devices that keep time and won't get updates, and put their replacement on a calendar before 2038.

The point

Y2K got fixed because everyone could see the deadline coming. Y2038 is sneakier. Its deadline moves toward you with every date you calculate, and the code that breaks first is the code looking furthest ahead, which is usually the code handling money, contracts, and security.

Pick the longest-lived date your system promises anyone. Convert it in the Epoch Converter. If the number is bigger than 2,147,483,647, your 2038 isn't in 2038. It's today.