The Epochalypse Project
90 comments
·May 11, 2025Waterluvian
I think this effort would benefit from trying to qualify what “unpredictable ways” actually means. If anyone is testing devices, a catalog of test results describing the actual failure modes that were revealed would help make this whole thing more concrete.
I think many software engineers know that if you want to make any organization care about this type of issue, you need to be ready to demonstrate the severity and impact.
calibas
Worst case scenario, it bricks your device: https://issuetracker.google.com/issues/36928638?pli=1
Even if the system boots properly, there's various critical systems that depend upon having the correct time. Say goodbye to things like HTTPS and SSL/TLS certificates.
luckylion
Will the root-certificates still be trusted in 12 years? Will we largely use the same TLS versions? And if systems can be updated to account for that, shouldn't they also be able to be updated to deal with the timestamps limitation?
moffkalast
For comparison I've revived a decade old Axis PTZ camera recently and it can't be used with HTTPS because it only supports TLS 1.0 which is deprecated across the board these days lmao. The UI is so bugged out it's not possible to change the default username and password anymore.
There's two kinds of internet connected devices these days, those that keep getting updated and those that drift into incompatibility and die as the rest of the ecosystem evolves around them. If these supposed critical devices will still be in use in 12 years without any maintenance then they're unlikely to have any actual importance.
lambdaone
It means 'anywhere between being bricked and no problem at all, and we can't give you any idea of how severe or how likely any of those possiblities are'. The only way you can really know is to thorougly audit your system and/or test it. Preferably both.
AndrewKemendo
So that means the best tool is a 2038 test environment - which people then install their application(s) and test it e2e to see what the impacts are.
However, I’m not sure how you make a 2038 test environment
It assumes that the OS/Kernel etc… are defacto frozen to 2025 or whatever increment until 2038
What was the y2k solution for the people that implemented those fixes in the 90s?
null
TacticalCoder
[dead]
jcul
libfaketime is useful for testing these kinds of things.
It intercepts system calls to get the time and reports a fake time to the application.
jbeninger
Demonstrate? Or just scaremonger?
Y2K showed that you don't need details beyond vague threats of "medication administered at the wrong time" and "planes falling out of the air" to get organizations and the public to care. No idea how that's going to tie into the conspiracy-heavy media landscape we inhabit now.
(Note I do think this is a serious issue that needs to be addressed. And I'd love to see specific examples. I'm just pushing back against the idea that examples would make much difference to advocacy efforts)
bongodongobob
What? Y2K did have many demonstrable problems... Having a 2 digit year did obviously cause problems. The reason nothing happened is because a shit ton of time and money was spent making sure it didn't.
jbeninger
Agreed. My point is that the orgs paying for all these updates were mostly motivated by the vague claims of experts rather than concrete examples
BeFlatXIII
“Planes falling pit of the sky” still gets used both as an example of overblown Y2k fear-mongering AND the reason why all those quiet preparations were necessary.
msla
Is there any plausible mechanism for Y2K bugs to cause planes to fall from the sky?
jsd1982
I fixed a recent Y38 bug in some classic ASP code. The bug was nothing more than a simple `Date() + 5000` computation (adding 5000 days to the current date) as a sort of expiry date applied to something; I don't recall the exact details. VB6 did not take kindly to computing any date value beyond the Y38 max and threw an error. In practice this error ended up denying service to everyone even though the Y38 max date was 14 years in the future. You never know what little bugs like that are lurking in such legacy code.
potatoman22
I feel like the hard part is flashing the new firmware
NelsonMinar
"Epochalypse" is a nice coinage. Not a new one either, this 2017 article attributes it to Mikko Hypponen (of F-Secure). https://www.tomsguide.com/us/2038-bug-bh2017,news-25551.html
teuobk
Goes back at least slightly before that, as I've had 2038epochalypse.com registered since March 2017, but I can't recall whether I thought I was being clever or whether I heard it somewhere else.
web007
I've had my "2038 consulting" sites since Feb 2011, but someone got epochalypse dot com registered August 2007.
LilBytes
Heh, I've got five domains of a similar name too. Going to reach out to the owners of the website this post is referring to and see if they want them.
AndrewDucker
Telling home users to check that their existing smart devices will still work in 13 years seems like overkill. It seems unlikely that more than a tiny fraction of them will still be in use then, if any.
Businesses installing new smart infrastructure and devices will need to pay attention to this, and in 10-15 years they'll need to work out what to replace, of course.
0xDEAFBEAD
Agreed. A serious approach to this problem would be: Identify critical computers which are currently 13+ years old (most likely embedded systems). Assume that the same sorts of systems will be 13+ years old in 2038. Focus on raising awareness with that particular target audience, e.g. give talks about the 2038 problem at embedded systems conferences. Try to get it included in university curricula. Etc.
cranberryturkey
15 years ago i was working at a startup in SV and a kid we hired was saying how he was sad he missed out on y2k because he was too young. I filled him with joy when I mentioned the 2038 bug. lol
ks2048
Who will register a domain for the upcoming year 292271025015 problem?
thrance
Y292B271M25K15 is less catchy than Y2K
RetroTechie
Things to keep you busy until then:
https://en.wikipedia.org/wiki/Time_formatting_and_storage_bu...
mkj
Are they doing anything to fix it or just raising awareness?
Here's an example of measuring packages that report warnings for software that has suspicious conversions. Compile with `-Wconversion` with both 32-bit and 64-bit time_t, and see what the difference is. https://github.com/mkj/yocto-y2038
That is using yocto, but you could probably do something similar with other less-embedded distros too, if you can rebuild the world.
FWIW I didn't find much interesting with that apart from busybox dhcpd.
rvba
It looks mostly like a project for self promotion of the two authors. Maybe they offer some consulting services.
Funniest is that one of them wrote that they have "learned about it after Y2K bug". I thought one learns about this overflow in a "introduction to programming" class...
Sardtok
It also says nothing about a formal education, just that he has worked in IT since his teens. I didn't hear of the 2038 problem myself until the whole Y2K debacle, but then, I was in my teens at the time.
zokier
btw yocto has been using 64 bit time_t since last year: https://docs.yoctoproject.org/dev/migration-guides/migration...
panzi
When will milliseconds since the Unix epoch not be precisely representable in IEEE double anymore? (As it's used in JavaScript.)
OutOfHere
Fwiw, it's much worse for 64-bit nanoseconds, running out in the year 2262 for signed, and the year 2554 for unsigned. As for who needs nanoseconds, trading systems, particle physics, and globally distributed systems do.
panzi
Which systems use a single variable for nanoseconds time? The APIs I know of all use a struct with two members, one for seconds and the other for the nanoseconds within the second.
kbolino
It's a pretty common format for timestamps on modern file systems used by Unixy operating systems (e.g. ext4, XFS, APFS, ZFS, btrfs, etc.).
Arcorann
MAX_SAFE_INTEGER = 2^53 - 1 = 9007199254740991. The next integer 2^53 is representable, while the following one 2^53 + 1 isn't.
2^53 + 1 milliseconds = 9007199254740993 milliseconds = 104249991 days 8 hours 59 minutes 0.993 seconds. Since the zero point is midnight 1970-01-01, we reach the first non-representable millisecond at 287396-10-12T8:59:00.993 (be careful to use the Gregorian leap rule if you want to calculate this manually).
fmbb
In the year 287390 (285420.9 years after 1970) according to my calculations using DuckDuckGo’s calculator.
If you ask ChatGPT it’s:
= 285,616 years after 1970
= Year 285,616lionkor
Why would you ask ChatGPT?
hackyhacky
AI is the next big thing, I hear.
fmbb
Some people just want the wrong answer.
Thorham
That seems a bit small seeing how doubles can represent 53 bit integers accurately.
tomsmeding
>>> 2**53/(1000*3600*24*365)+1970
287586.41472415626
dgfl
Well, 2^53 milliseconds is indeed 285 414 years.
echelon
Epochalypse is clever. I'd been calling it Y2K38 so it made sense to people outside the industry.
phtrivier
I witnessed my first y38 bug a couple weeks ago - just as a matter of someone doing forecasting in a system with an incorrect casting.
At least, the good part is that people will get "hunches" about y38, just like you start getting "hunches" about bugs related to locales, time zones, character encodings, currency roundings, etc...
I don't know if there are courses, books, etc... about all those matters that are definitely non "computer sciency", but occupy so much of our engineering time ?
> And what’s worse, malicious threat actors can manipulate time synchronization protocols in many cases to trigger this vulnerability at the time of their choosing.
If you switch to 64 bit timestamps, and the network protocol supports dates > 2038, can you then just trigger the rollover bugs by pretending it's 2*64 - 1 seconds after epoch start?
Also, if the actions are potentially so severe, and NTP (or whatever is used) so vulnerable, why haven't we seen many such attacks in the wild?
Update: to be clear I'm not arguing that there isn't a problem, I've already run into it myself. I'm trying to understand how severe it is, how exploitable, and how robust a solution could be.