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?#

Observed Some have, and the clearest cases are in the open-source commons, where the work is visible in public repositories rather than asserted in a press release: the Linux kernel, the GNU C Library, and Debian's time64 effort have done the substantial work of moving to 64-bit time.

Unexamined Among proprietary vendors the picture is far harder to establish. Claims of 64-bit hardware are sometimes offered as though they settled the question, but as the FAQ sets out, a 64-bit processor or operating system is not the same thing as a 2038-safe system. We are not aware of a major consumer vendor that has published a substantive account of its rollover readiness. 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 telling. 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.

Reported There are early signs of movement, though they remain thin and largely unpublished. Some organisations have begun naming an internal owner for rollover readiness — a role we have heard described as a "Y2K38 lead" — and a small number of large-scale testing efforts are under way. We record this as reported rather than observed: the accounts reach us through practitioners describing their own organisations, and few have been made public. That is consistent with everything above. Naming an owner is a low-cost, low-exposure step; announcing one is not. The signal is real, but its faintness reflects the disclosure incentives rather than the extent of the work.