Evidence#

The documented track record — the failures and near-misses that make 2036–2038 an engineering forecast rather than a prediction.

Are there public examples of 2038-class issues?#

Yes — though public examples are rarer than they should be, because disclosure incentives are poor. Several concrete categories exist.

Observed Modern software is already hitting 2037 boundaries. Some calendar and scheduling systems visibly fail or refuse to schedule beyond late 2037, which shows that modern applications can still inherit 32-bit assumptions.

Databases carry documented time limits. Some timestamp types and schemas historically encode 32-bit epoch seconds, creating boundaries that matter for long-lived records.

Time-synchronisation infrastructure acts as an early warning. The 2036 NTP boundary will surface first, and legacy deployments persist despite long-available patches.

Observed Industrial and critical-infrastructure disclosures are now concrete. In October 2025, CISA issued an ICS advisory (ICSA-25-296-03, CVE-2025-55067) covering improper handling of Unix time past the 2038 rollover in an automatic tank gauge (ATG) — the kind of console that monitors underground fuel storage, including leak detection. When the clock crosses 19 January 2038 the affected device resets to 1901, producing administrative lockout, loss of login and history access, termination of leak-detection routines, and corrupted logs. Because the fault is time-triggered, an attacker able to manipulate the device's time can induce the same denial of service today. The leak-detection failure carries a physical-safety dimension, not merely a data one: an ATG that cannot complete a leak test is a safety control that has quietly stopped working. The advisory identifies the specific product; what matters here is the failure class. This is a time-handling fault, and should not be confused with the separate, unrelated 2026 advisories about internet-exposed tank gauges.

Reported A case in France involving Paris transit rolling stock is a rare court-visible example, because the dispute reached a tribunal rather than staying private. It concerns time-related exposure in embedded train software and, centrally, who is responsible for addressing it — the operator (RATP) and the manufacturer (Alstom) take different views. A Paris administrative tribunal ruled in late 2025; the decision is under appeal, and the questions of fault and cost remain contested between the parties. We flag it not to apportion blame — both sides raise legitimate points, and the matter is unresolved — but because it shows the responsibility question this FAQ keeps returning to being worked out in court rather than in advance.

Will every failure around 2038 be a 2038 bug?#

No — and assuming so will mislead triage. Rollover dates attract other latent bugs that aren't themselves rollover faults but cluster nearby: a well-known case from the Y2K period was a leap-year calculation error that broke a line of equipment on New Year's Eve 1999 and was widely mistaken for a Y2K bug. Around the 2036–2038 window, expect a mix of genuine rollover faults, unrelated bugs surfaced by the same forward-time testing, and vendor-specific quirks that merely resemble the pattern. Telling them apart matters both operationally — so effort goes where it belongs — and for public communication, so the account stays accurate rather than attributing everything in sight to "the 2038 bug."

Why don't we see more public industrial cases?#

Because the system discourages speaking openly. Acknowledging unremediated exposure creates legal and reputational risk; engineers often cannot speak publicly; vendors face liability in admitting flaws in shipped products; and public companies face potential disclosure obligations.

The result is structural silence: the people who know often can't talk, and the people who can talk often don't know.

Has anyone actually fixed it?#

Reported Some have, and a few have said so publicly. Apple has stated that it prepared its hardware and software well ahead of time; the Linux kernel and the GNU C Library have done the substantial work of moving to 64-bit time. Beyond a handful of such cases, public confirmation is thin: asked directly, large organisations tend to respond with silence or a brief assurance that the risk is "under control", rarely with detail. That pattern is itself informative. It is consistent with the disclosure disincentives above — fixing quietly carries no penalty, while saying so invites scrutiny — so the absence of reported problems should not be read as evidence that the problem has been handled.