Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Epochalypse Project

epochalypse-project.org

Post reply on HN
Print view View original

81–90 of 91 posts

Re: The Epochalypse Project

#81

Post by jcul »

AndrewKemendo wrote: post #21
Waterluvian wrote: post #9

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…

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?

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.

https://github.com/wolfcw/libfaketime

Re: The Epochalypse Project

#82

Post by Arcorann »

panzi wrote: post #8

When will milliseconds since the Unix epoch not be precisely representable in IEEE double anymore? (As it's used in JavaScript.)

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).

Re: The Epochalypse Project

#83

Post by teddyh »

moffkalast wrote: post #70
luckylion wrote: post #38

Earlier quoted context omitted.

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?

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 di…

For those in a similar situation, http://frogfind.com/> is useful.

Re: The Epochalypse Project

#86

Post by cesarb »

kbolino wrote: post #71
panzi wrote: post #67

Earlier quoted context omitted.

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.

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.).

At least ext4 (and its predecessors ext2/ext3) uses 32-bit seconds for the timestamps, and has separate fields (available only when the inode size of the filesystem is greater than 128 bytes) for nanoseconds and for extending the seconds fields to 34 bits.

Re: The Epochalypse Project

#87

Post by LilBytes »

teuobk wrote: post #51
NelsonMinar wrote: post #49

"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

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.

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.

Re: The Epochalypse Project

#88

Post by kbolino »

cesarb wrote: post #86
kbolino wrote: post #71

Earlier quoted context omitted.

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.).

At least ext4 (and its predecessors ext2/ext3) uses 32-bit seconds for the timestamps, and has separate fields (available only when the inode size of the filesystem is greater than 128 bytes) for nanoseconds and for extending the seconds fields to 34 bits.

True enough [1] but the end result is actually a slightly shorter time range ("only" 544 years vs. 584 years for a "true" 64-bit ns-resolution timestamp). Though, admittedly, when we get anywhere near to the year 2514 and happen to still be using ext4 (or yet another extN+1), the format can always be extended again.

Also, I may have been wrong about XFS on Linux at least; though the data structures are not as easy to follow as for ext4, they seem to be using struct timespec64 for all times, which has both separate fields for seconds and nanoseconds as well as a 64-bit-wide seconds field [2], covering a range of 584 billion years.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...

[2]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...

Re: The Epochalypse Project

#89

Post by johnklos »

The solution is simple: go back in time and get legislation passed to mandate the release of source code for devices that the original manufacturer no longer intends to support.

That might be imposssible right now, and not just because of the time travel thing. While it's a good idea, and while people are working to get legislation passed that would prevent the forced obsolescence of products by companies requiring, then no longer supporting, public servers, for instance, companies would fight to the death any requirement to make their source available.

But the problem isn't only theirs - open source projects that are steered by corporations often lack the willingness to expend some work now in order to save work decades from now.

For instance, NetBSD moved to 64 bit time on all platforms using clever versioning to maintain compatibility with 32 bit timestamps. They did this on 32 bit architectures, too, back in 2012. [0], [1]

Linux, on the other hand, has no shortage of people who either want to drop 32 bit support entirely or who think that the work to modernize 32 bit support isn't worthwhile (because, in part, they've forgotten that embedded Linux is a thing, and they also don't care about people who can't afford modern hardware). The 64 bit time transition for 32 bit platforms has taken ages, but is thankfully finally underway. [2]

There's practically no hope for corporations. If they aren't given stuff that's already fixed (that is, if the fix isn't already baked in to the Linux they choose to use), they're certainly not going to "invest" resources in fixing things from the past. Heck - it took Google more than a week to fix issues with Chromecasts that came from bad planning. [3]

What can we do? Most people aren't going to decide on a purchase based on whether their product might stop working in 2038 unless we make it very easy for them. We should test more things and point out when products will fail. Of course, nobody is going to care if their wifi device bought in 2025 won't run in 2038, but if someone told you that a $50,000 car's infotainment system will stop working, they might care.

[0]: https://wiki.netbsd.org/symbol_versions/

[1]: https://web.archive.org/web/20200122035908/https://twitter.c...

[2]: https://wiki.debian.org/ReleaseGoals/64bit-time

[3]: https://www.theregister.com/2025/03/13/google_chromecast_fix...

Post reply on HN