What exactly happens in 2038?

At 03:14:07 UTC on 19 January 2038 a signed 32-bit counter of seconds since 1970 reaches its maximum of 2,147,483,647. One further second wraps it to its most negative value, which reads as 20:45:52 UTC on 13 December 1901, so affected systems report a date 136 years in the past.

Is my computer affected by the Year 2038 problem?

Almost certainly not. Any 64-bit build of a current operating system uses a time type wide enough to last billions of years. The remaining risk sits in 32-bit embedded devices, firmware that is never updated, and file formats with fixed 32-bit timestamp fields.

Why does the date wrap to 1901?

Because a signed integer that exceeds its maximum wraps to its minimum, and the most negative 32-bit value counts backwards from 1970 by the same 68 years. That lands on 13 December 1901, so the clock appears to jump from 2038 into the Edwardian era.

Has the 2038 bug caused problems already?

Yes. Any calculation reaching past January 2038 overflows today, so thirty-year mortgages began failing in 2008, and long-dated bonds, pension forecasts and far-future certificate expiry dates have all triggered it since. The symptom is usually a date in 1901 or a nonsensical negative duration.

The Year 2038 Problem | localdatetime.now

At 03:14:07 UTC on Tuesday 19 January 2038, a counter that most of the world's software once relied on reaches its maximum value. One second later it wraps around to its most negative value, and any system still using it believes the date is 13 December 1901. That is the Year 2038 problem, sometimes called the epochalypse, and it is the direct descendant of the same arithmetic thinking that produced the year 2000 scare.

This article sets out exactly why the overflow happens, what the boundary looks like in practice, which layers of the stack were fixed years ago, and which are still quietly waiting. Any timestamp discussed here can be checked against a real date with the Unix timestamp converter.

What Is the Year 2038 Problem?

It is the overflow of a signed 32-bit integer used to count seconds since the start of 1970. The largest value such an integer can hold is 2,147,483,647, and that number of seconds after the epoch falls on 19 January 2038, after which the count cannot increase.

The counter in question is time_t, the C type that Unix and its descendants have used for the current time since the 1970s. When it was chosen, a range of sixty-eight years past the epoch was more than any machine of the era would live to see. The underlying representation is explained in Unix epoch time explained, and the only relevant property here is that it is an integer with a fixed width.

Why Does 32 Bits Run Out?

A signed 32-bit integer has 4,294,967,296 possible values, split evenly between negative and positive, so the largest positive value is 2,147,483,647. Counting one second at a time from 1970, that ceiling arrives after roughly 68 years and 19 days.

What happens next depends on the language, but the classic behaviour in C is silent wraparound. Adding one to the maximum produces -2,147,483,648, which is 20:45:52 UTC on 13 December 1901, a Friday. Nothing raises an error; the date is simply wrong by 136 years, and it is wrong in a direction that makes every comparison behave backwards. A certificate becomes expired before it was issued, a cache entry appears to be a century stale, and a scheduler concludes that a task overdue by decades should run immediately and repeatedly.

What Has Already Been Fixed?

Most of the visible internet, some of it decades ago. Any 64-bit build of a modern operating system uses a 64-bit time_t, which does not overflow for around 292 billion years, and 64-bit hardware has been the default for general-purpose computing since the mid-2000s.

64-bit operating systems: Linux, the BSDs, macOS and Windows all use a wide time type on 64-bit builds and are unaffected.
32-bit Linux: the kernel gained 64-bit time support in 2020, and the C library followed with an option to compile 32-bit userspace against a wide time type.
Java and JavaScript: both count milliseconds in a value far wider than 32 bits, so neither has ever been exposed to this particular boundary.
Modern filesystems: ext4 with large inodes and the newer filesystems store timestamps with enough width to run well past 2038.
Databases with 64-bit types: PostgreSQL stores timestamps in a 64-bit value and has no equivalent ceiling.

The pattern is that anything actively maintained and recompiled in the last decade has almost certainly been dealt with. The Year 2038 problem is not a story of neglect so much as one of uneven reach.

What Is Still Broken?

Everything that cannot be recompiled, and everything that wrote 32 bits into a format rather than a variable. Embedded devices are the largest category by count: industrial controllers, meters, medical equipment, vehicle modules and network appliances built around 32-bit processors and shipped with firmware nobody intends to update.

File formats and protocols are the subtler half. A timestamp field that is 32 bits wide on disk stays 32 bits wide no matter how modern the software reading it, so the fix requires a format revision and a migration rather than a rebuild. MySQL's TIMESTAMP type is a well-known example, with a documented range that stops at exactly the 2038 boundary; its DATETIME type does not share the limit, which makes the column choice discussed in why you should store dates in UTC more consequential than it first appears. Older archive formats, some binary log formats and a good deal of bespoke serialisation carry the same constraint.

Is the Year 2038 Problem Already Causing Failures?

Yes, and it has been for years, because software regularly does arithmetic on future dates. Anything computing a date beyond January 2038 hits the ceiling today, long before the boundary itself arrives.

Thirty-year mortgages crossed the line in 2008. Long-dated bonds, pension projections, insurance terms and lease schedules have all produced overflow failures in systems that were otherwise working perfectly. Certificate authorities have to be careful with long-lived roots for the same reason, and expiry values set deliberately far in the future are a common trigger. The failure looks like a date in 1901 or a negative duration, and it is usually reported as a display glitch rather than as an arithmetic overflow, which delays the diagnosis.

What Should You Actually Do?

Not much, if you are building on maintained 64-bit software, but a few checks are worth making:

Audit stored formats, not just code: a 32-bit field on disk survives every recompile.
Test with dates past the boundary: feed 2040 into anything that does date arithmetic and see what comes back.
Check embedded and vendor firmware: ask suppliers directly, because these devices rarely surface the problem until it happens.
Prefer wide types in new schemas: a 64-bit integer or a native timestamp type costs nothing extra today.
Watch the smaller siblings: some formats overflow earlier still, and unsigned 32-bit counters merely move the failure to 2106.

The related question of how timestamps should be written down rather than stored is covered in ISO 8601 explained, and a text timestamp produced by the ISO 8601 formatter has no width limit of this kind at all.

It is also worth keeping the scale of the Year 2038 problem in proportion. Unlike the year 2000 scare, this one has a single, precisely known cause and a single, well-understood fix, and the fix has already been applied to the platforms that carry most of the world's traffic. The residual risk is concentrated in long-lived hardware that was cheap to buy and is expensive to replace, which is exactly where inventory records tend to be worst. Anyone responsible for such equipment has roughly a decade to find it, which sounds generous until you consider how long procurement cycles run in the industries concerned.

Conclusion

The Year 2038 problem is a fixed appointment: 03:14:07 UTC on 19 January 2038, when a signed 32-bit second counter runs out and wraps to 1901. Mainstream 64-bit systems dealt with the Year 2038 problem long ago, but embedded firmware, fixed-width file formats and a few database types have not, and any code that reasons about dates far in the future is already meeting it. Check where your own timestamps sit with the Unix timestamp converter, or see the current instant in every format on localdatetime.now.

The Year 2038 Problem: When 32-Bit Time Runs Out