The Epochalypse Project#
Time Integrity & Epoch Rollover Risk (2036–2038)
On 2038-01-19 03:14:07 UTC, the ubiquitous 32-bit signed Unix timestamp (time_t) reaches the end of its range; immediately afterwards, systems that still rely on it may experience incorrect time calculations, mis-ordered events, crashes, or other failures — unless they are remediated or architected to tolerate the rollover.
Attackers don't need to wait. Weaknesses in time-synchronisation mechanisms and time-dependent logic can be exploited today by inducing or amplifying time anomalies — see Public safety.
This is not science fiction. It is a real engineering and cybersecurity risk affecting systems we rely on daily — from industrial automation and telecom infrastructure to embedded devices and long-lived operational technology.
Why should you care?#
Time is a shared dependency — the coordination backplane of the digital world. When timestamps become incorrect, or when systems disagree about time, failures can be hard to predict and harder still to diagnose.
Potential impacts include incorrect scheduling or logging (mis-ordered events, audit gaps); failures in time-based authentication, token validation, or certificate handling; data corruption or replication errors in time-ordered systems; monitoring and alerting that misfires in either direction; and disruptions to industrial processes or safety-critical systems.
Not every system will fail at the rollover moment, and not every failure will be catastrophic. But the risk is real, widespread, and concentrated where patching and replacement cycles are slow.
Explore the site#
The detail lives on five focused pages:
- The FAQ — what the problem is, the technical reality, and the vocabulary to describe it.
- Public safety — why this is a safety problem, and how cybersecurity weaknesses make it exploitable today.
- Evidence — the documented failures and precedents behind the forecast.
- How can I help? — find your exposure, test safely, mitigate, and plug into the response.
- Further reading — the sources behind the claims on this site.
What is the 32-bit timestamp problem?#
Many systems represent time as a 32-bit signed integer counting seconds since 1970-01-01T00:00:00Z ("Unix time"). When that counter overflows, affected systems may interpret subsequent timestamps as dates in 1901.
| Timestamp | |
|---|---|
| Last representable second | 2038-01-19 03:14:07 UTC |
| After overflow | 1901-12-13 20:45:52 UTC |
This is the Year 2038 problem (Y2038 / Y2K38). It shows up in legacy Linux/Unix environments and older libc and toolchains; in widely used network protocols and common data formats; in embedded and industrial devices using 32-bit time; in long-lived appliances and IoT devices with unclear ownership or update paths; and in databases that store time as 32-bit epoch seconds.
The core risk pattern: time-representation limits, plus long-lived deployment, plus slow remediation. The FAQ explains the mechanics in full.
Related rollover events#
2038 is not the only time-related rollover in this critical window:
| Event | Date |
|---|---|
| NTP era rollover | 7 February 2036 |
32-bit time_t rollover |
19 January 2038 |
| GPS week-number rollover | 20 November 2038 |
(The FAQ has a more comprehensive timeline, including the long-tail.)
These affect different technologies but often intersect in real systems. The common thread: time assumptions that were safe when systems were young become dangerous when systems live for decades.
Why this is hard#
The challenges compound. Many affected devices are designed to run ten to thirty years. Embedded and OT constraints can make patching difficult, risky, or impossible. Supply-chain opacity means organisations often don't know which components carry time limits. Shared dependencies let time failures cascade across systems that assume consistent timestamps. The incentives are mismatched: remediation costs are local while the benefits are diffuse. And much of the problem lives in the public commons — free and open-source software in particular — where it is unclear who should fund or oversee remediation.
Even where fixes exist, remediation takes time: talent, inventory, testing, vendor engagement, change windows, operational-risk management. This is a coordination problem as much as a technical one — and the layer to coordinate between the efforts is only now beginning to form.
What we're doing#
The Epochalypse Project is a collaborative effort to improve shared understanding of rollover and time-integrity risk patterns, develop and share safer testing methodologies, document observed device and system behaviour, support responsible vendor engagement and coordinated mitigation, and connect practitioners across sectors and standards bodies.
Since 2025 that work has taken concrete shape. Members of the project co-edit the ITU-T Study Group 17 Technical Paper on 2038-class rollover risks (XSTP.epoch), and convene the FIRST Time Security SIG, which is increasingly the venue where the relevant standards efforts coordinate. How can I help? has the detail on who is doing what.
We aim to be practical: focus on what can be tested, measured, documented, and improved today.
Who we are#
The project was founded by Trey Darley and Pedro Umbelino, cybersecurity researchers with backgrounds spanning vulnerability research, incident response, and long-lived digital infrastructure.
This is a volunteer-driven effort to help the community coordinate earlier, test more safely, and reduce surprise as these rollovers approach.
How you can help#
You don't need to touch sensitive systems to contribute. If you rely on long-lived devices — routers, NAS units, IoT hubs, appliances — check whether their vendors state 2036/2038 readiness, and report the gaps you find.
If you operate or build long-lived systems, How can I help? walks through finding your exposure, testing safely, mitigating what you can't fix in time — and sets out the open questions where research expertise is most needed.
Whatever your corner, the way in is the FIRST Time Security SIG.
Join the effort#
We're building a shared map of risk patterns, testing methods, and mitigation paths — so fewer organisations discover these problems too late and alone.
If you can help test safely, document behaviour, or improve guidance, you're welcome here.
Let's reduce catastrophic surprise — together. 🕊️
Epistemic note: this page reflects current understanding as of the date in the footer. Specific behaviour varies by system, implementation, and deployment context.