FAQ — Epoch rollover risk (2036 / 2038)#

What the 2036/2038 rollovers are, why "we'll upgrade later" fails in practice, and the words to describe it.

The Basics#

What is the "Year 2038 problem"?#

Many systems store time as a 32-bit signed integer counting seconds since 1970-01-01T00:00:00Z ("Unix time", time_t). That counter reaches its maximum value and overflows at 2038-01-19 03:14:07 UTC.

After overflow, some systems interpret the time as a date in 1901, causing incorrect calculations, mis-ordered events, crashes, or other failures.

It will not all happen at once, though, and no one can say precisely what will. Behaviour past the boundary is system-specific: a device may crash, freeze, or — the worst case — keep running while producing wrong results, with no error to draw attention to it. Failures won't arrive in a single synchronised wave either; they surface unevenly, before and after the date, often where they are hard to test and harder to attribute. That unpredictability is not hand-waving — it reflects how varied the affected systems are, which is why mapping where exposure lives and testing it in place matter more than any single forecast.

Why was time stored in only 32 bits in the first place?#

Because memory used to be scarce and expensive, and engineers economised wherever they could. When these conventions were set, a 32-bit field was a sensible trade-off, and it became deeply embedded across the industry through the following decades. Even after 64-bit systems became common, 32-bit time persisted in equipment that doesn't need much processing power — sensors, valves, controllers — on the assumption that updates would be made in good time. The assumption was reasonable; what often failed was the follow-through, as the records of where those systems are and how they encode time were gradually lost.

What will actually happen on 19 January 2038? Will everything crash at once?#

Short version: it won't all happen at once, and the behaviour is system-specific and hard to predict. The fuller answer is folded into What is the "Year 2038 problem"? above.

Is 2038 one event, or part of a sequence?#

It is one of a family of related events. The table below sets out the reference points each representation counts from, the rollovers already behind us, and those still ahead:

A rollover is range exhaustion of a representation, not a change to the epoch it counts from: the reference points stay fixed; what runs out is the room to count from them. The 2036 boundary can reveal failure modes before 2038, especially through time-synchronisation dependencies, and the two 2038 events — time_t in January and the GPS week number in November — are structurally distinct problems that happen to fall in the same year. (The November 2038 GPS time assumes the current GPS–UTC offset of +18 seconds, which future leap-second decisions could shift.)

The last two rows are different in kind. The 2106 row is what you get if you "fix" 2038 by switching to unsigned 32-bit — it defers the rollover rather than removing it. The 64-bit signed horizon, by contrast, lands roughly 292 billion years out, well beyond the Sun's remaining lifetime; it takes the rollover off any timescale a deployed system could survive on. We give no weekday for that row on purpose: the arithmetic is trivial, but the civil scaffolding needed to read it — leap-year conventions, possible calendar reforms, the slow drift of Earth's rotation — is nowhere near stable across 292 billion years. The deeper point is that the meaning attached to a date decays far faster than a clock's precision, because that meaning is carried by institutions, and institutional memory is short. Within roughly three centuries the Christian church had already lost any authoritative record of the birth and death dates of its own central figure; the dates observed today are later reconstructions, chosen on symbolic grounds rather than from evidence. A clock can pinpoint an instant 292 billion years out — but nothing will be left that can say what that instant meant.

Why isn't this solved already?#

Two reasons, and the first is the uncomfortable one: it is genuinely hard. Moving to 64-bit time is not a one-line patch but an ABI-level change that has to hold end-to-end — kernel, libraries, applications, database schemas, file formats, and protocol fields. In embedded and long-lived systems it can mean firmware rework, or physical replacement where there is no upgrade path at all. And the remediation pathways are still only partly mapped: for a large share of the installed base there is no clean fix on the timeline available, which is why the work now spans harm-minimisation as much as repair, and why even measuring exposure reliably remains an emerging discipline.

The second reason compounds the first: the difficulty is largely invisible. 32-bit time is a deep, load-bearing assumption rather than obvious legacy code, so it seldom surfaces where attention, budget, and responsibility are allocated — and few have a reason to own the fix before something breaks.

What makes the problem persist?#

Several interlocking conditions keep it alive. 32-bit time is not "old code"; it is a deep assumption embedded so thoroughly that systems treat it as axiomatic. Software built for three-to-five-year cycles is deployed into infrastructure that lasts twenty to fifty years. Multi-layer supply chains make "who owns the fix?" genuinely unclear. Testing is hard and sometimes impossible, because you often cannot safely set production clocks forward, and laboratory tests cannot fully replicate complex, interconnected behaviour. And the incentives are misaligned: costs are local, benefits are diffuse, and disclosure is legally uncomfortable.

Isn't this "just like Y2K"?#

It is related, but different. Y2K was largely a data-formatting problem (two-digit years). 2038 is more often a systems-integration problem, where failures appear at boundaries — between platforms, libraries, protocols, devices, databases, and supply chains.

It is also worth remembering that Y2K did not turn out fine by luck. It turned out fine because of an unusually large, coordinated remediation effort.

The scale is different too. The population of connected, potentially affected devices today is far larger than in 2000 — by most informal estimates orders of magnitude larger, though no authoritative inventory exists — and much of it sits in embedded and industrial systems that are harder to find and harder to touch than the mainframes and business software that dominated Y2K remediation.

A more cautionary precedent is IPv4 → IPv6: a load-bearing field outgrowing its protocol, with the fix available throughout. Specified in 1998, IPv6 first carried the majority of Google's traffic only in March 2026 — nearly three decades to retire a known limitation, and only once address exhaustion forced the issue. 2038, by contrast, has a fixed deadline rather than a slow squeeze, and no equivalent forcing function to concentrate minds.

Glossary#

Technical Reality#

If our computers are 64-bit now, aren't we safe?#

No — this is a common misconception, and it comes in two flavours. The first is that a 64-bit OS makes a system safe: it doesn't, because any single layer can still use 32-bit time — application code, libraries and toolchains, database column types, file formats, protocol and network fields, device firmware, or the API contracts between systems. "64-bit OS" is not the same as "2038-safe."

The second is that the problem will simply age out as old equipment is retired. It won't: 32-bit time is still being designed into new products, and 32-bit silicon continues to ship in volume, so the substrate is replenished roughly as fast as it retires.

And even genuine 64-bit time is not automatically permanent — the horizon depends on the storage resolution, not only the bit-width. A 64-bit count of whole seconds from 1970 lasts about 292 billion years; at millisecond resolution that falls to roughly 292 million years, at microseconds to about 292,000 years, and at nanoseconds to roughly 292 years — a rollover in the 23rd century, around 2262. Nanosecond 64-bit timestamps are common (Linux's real-time clock and several language runtimes use them), so "we moved to 64-bit" only settles the question once the resolution has been checked for headroom as well.

When did 32-bit POSIX time stop being used?#

It didn't. 32-bit assumptions persist today, sometimes in modern products. This is not a historical artefact — it is a copied design pattern. The transition to 64-bit time has been gradual, inconsistent, and incomplete, especially across embedded systems, compatibility builds, and long-lived data formats.

Upstream, much of the core transition is in fact done — the Linux kernel, glibc, and Debian's time64 work are largely complete. But moving to 64-bit time is an ABI change, not a bug that can be silently backported, so the embedded and long-tail installed base lags well behind the upstream fix. One consequence is useful for defenders: because the fix cannot be quietly slipped in under an unchanged version string, an old version banner is a more reliable signal of exposure here than it is for an ordinary CVE.

What about AI-generated code and "vibe coding"?#

Large language models are trained on decades of existing code — including decades of 32-bit time assumptions. When developers lean on statistically common patterns, models can reproduce exactly the patterns that need remediation. There are still few widely deployed guardrails — lint rules, static analysis, CI checks — that consistently warn "this fails in 2038."

So the risk is not only legacy code. It can be actively reintroduced.

The substrate is also still expanding: 32-bit silicon continues to ship in growing volumes into products that will outlive 2038. The risk, then, is that we automate the propagation of the very pattern we most need to retire. Two cheap, high-leverage interventions remain undone: making coding assistants sensitive to the 2038 pattern, and sweeping open-source libraries to surface and flag time-handling code. Neither is yet anyone's job.

What kinds of systems are most at risk?#

Not the ones people tend to picture. Consumer-electronics turnover is fast; the risk concentrates in long-lived, low-visibility infrastructure.

The devices you don't think about are where the risk concentrates.

What's the relationship between 2038 and NTP?#

NTP has its own rollover boundary: 2036-02-07.

The fix for it has been available in ntpd's stable branch since 2014 — though it is not always enabled by default, so a current version is necessary but not always sufficient — and legacy deployments persist regardless. The project's most recent scan of roughly 125,000 internet-facing servers whose NTPd version could be identified found over 40% at high or medium risk of the 2036 rollover. A further subtlety compounds this: NTPv3 and NTPv4 share wire formats for backward compatibility, and without explicit version signalling two systems can interpret the same bytes under different semantic models, with knock-on effects for era-rollover handling.

There is also a present-day exposure here, independent of any rollover. Much of the world's time comes from a handful of large public services that billions of devices use by default, sometimes by hardcoded configuration — and independent measurement has found their resilience uneven and their adoption of integrity protection (NTS, which authenticates NTP) low, leaving many time exchanges open to manipulation in transit. Weak time today is the same attack surface the rollovers will stress further.

The practical lesson: "we have time" is not a remediation strategy.

What are the main technical fixes?#

There are a few main approaches.

1) Move to 64-bit time fields — the best long-term fix. Effective for any practical timeframe, but it must be end-to-end: kernel, libraries, applications, schemas, formats, and protocol boundaries.

2) Switch to unsigned 32-bit — buys time, not a cure. Defers the rollover to 2106, but breaks representation of dates before 1970 in many designs and creates a second rollover event later. A fallback, not a durable solution.

3) Use a different representation — for example Windows FILETIME, calendar-component types (DATETIME), or ISO 8601 strings. Each has trade-offs.

4) Replace the hardware. For embedded systems with no upgrade path, physical replacement is the only option.

What's the hardest part of remediation?#

Inventory. You cannot patch what you cannot find. Few organisations have a complete map of every place timestamps are stored, compared, transmitted, and computed — especially across suppliers and integration points.

Remote scanning and fingerprinting help, but they are triage for prioritising in-situ testing, not proof of safety: they can tell you roughly where exposure is likely to concentrate, not give an exact count or clear an individual system.