My brother in Christ, there’s more to time than just storing it. Every datetime library I’ve ever used only documents formatting/parsing support up to four year digits. If they suddenly also supported five digits, I guarantee it will lead to bugs in handling existing dates, as not all date formats could still be parsed unambiguously.

It won’t help you if time is stored perfectly, while none of your applications support it.

Regarding Y2K, it wasn’t horse shit - thousands upon thousands of developer hours were invested to prevent these issues before they occurred. Had they not done so, a bunch of systems would have broken, because parsing time isn’t just about displaying 19 or 20.

Y2K was definitely not only fear-mongering. Windows Systems did not use Unix timestamps, many embedded systems didn’t either, COBOL didn’t either. So your explanation isn’t relevant to this problem specifically and these systems were absolutely affected by Y2K because they stored time differently. The reason we didn’t have a catastrophic event was the preventative actions taken.

Nowadays you’re right, there will be no Y10K problem mainly because storage is not an issue as it was in the 60s and 70s when the affected systems were designed. Back then every bit of storage was precious and therefore omitted when not necessary. Nowadays, there’s no issue even for embedded systems to set aside 64 bit for timekeeping which moves the problem to 292277026596-12-04 15:30:08 UTC (with one second precision) and by then we just add another bit to double the length or are dead because the sun exploded.

Lmao I actively work with shortdates in a database because I have no control over how things are stored. They need to solve before 100 years have passed from the epoch, but at some point before then it’ll be fun to figure out if “58” in a date of birth is 1958 or 2058.

Fun fact, lots of VW modules think it’s August of 2094 for some reason.

Y2K wasn’t entirely fear mongering horse shit. There were quite a few important cogs in our digital infrastructure that were using code that would not work past 1999. It was necessary to terrify corporate ownership into paying to fix the code, otherwise they would have never done it.

Time I can deal with, timezones however, fuck that shit all to hell.

Programmers dealing with the timezones of asymmetric period binary and trinary star systems once we go interstellar 💀

Please no.

Well, I looked at a Year 10000 problem less than 2 hours ago. We’re parsing logs to extract the timestamp and for that, we’re using a regex which starts with:

\d{4}-\d{2}-\d{2}

So, we assume there to be 4 digits for the year, always. Can’t use it, if you live in the year 10000 and beyond, nor in the year 999 and before.

It’s a UX problem rather than a date format problem at that point. Many form fields require exactly 4 digits.

Luckily I’ll be retired by then.

Is there an ELI5?

It’s going to be significantly more than the year 33000 before we run out of 64-bit epoch timestamps.

The max value for signed 64-but epoch values is more than 292 billion years away, or 20 times the age of the universe itself.

So yeah, we’re basically solid forever with 64-bit

it’s mostly solved already

I wished I believe this. Or I guess I agree that it is solved in most software but there is lots of commonly used software where it isn’t. One broken bit of software can fairly easily take down a whole site or OS.

Try to create an event in 2040 in your favourite calendar. There is a decent chance it isn’t supported. I would say most calendar servers support it, but the frontends often don’t or vice-versa.

I’ve been curious about that myself. On one hand, it still seems far away. On the other hand, it’s a bit over 13 years away now and I have gear actively in use that’s older than that today.

Praise Vectron!