memes

... any discrepancies in the use of "year" as a 4 digit number vs a 5 digit number, are entirely a display issue (front end).

That's exactly how I read the meme. It would still require a change.

Whether that is displayed to you correctly or not, doesn't matter in the slightest. The machine will function even if you see some weird shit,

I'm not sure if this is some nihilistic stuff, or you really think this. Of course nothing actually matters. The program will still work even if the time is uint32 instead of uint64. The machine of course will still work as well. Shit, your life will go on. The earth continues to spin and this will for sure not cause the heat death of the universe. But aside from actual crashes and some functionality bugs, UI issues should be the ones you worry about the most. If your users are a bank and they need to date the contracts, and you only offer 3 digits for the year? I think you'll agree with me that if users don't like using your program, it's a useless program.

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.

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.

And it's represented as a 64 bits value, which is over 500 billions years.

Seems hyperbolic to assume we will be extinct by 9999.

Sure we’re heading for a climate crisis, but I don’t think all humans will be dead; Just the poorest.

The trick is to unplug our computer a few seconds before midnight on December 31st, 9999 and then plug in the wire again

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

Please no.

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.

There are so many problems there is an entire Wikipedia page dedicated to them.

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.

Well the USA is on Earth so obviously the earth calendar is the default.

It just counts up, according to this answer.