this post was submitted on 18 Dec 2024
1099 points (98.5% liked)

memes

10666 readers
1905 users here now

Community rules

1. Be civilNo trolling, bigotry or other insulting / annoying behaviour

2. No politicsThis is non-politics community. For political memes please go to [email protected]

3. No recent repostsCheck for reposts when posting a meme, you can only repost after 1 month

4. No botsNo bots without the express approval of the mods or the admins

5. No Spam/AdsNo advertisements or spam. This is an instance rule and the only way to live.

Sister communities

founded 2 years ago
MODERATORS
[email protected]
[email protected]
[email protected]
1099
We're being short-sighted (lemmy.world)
submitted 4 days ago by [email protected] to c/[email protected]
129 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 17 points 3 days ago* (last edited 3 days ago) (2 children)

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.

[–] [email protected] 5 points 3 days ago (1 children)

The comment you're replying to is really frustrating to me. It annoys me when people are so arrogant but also wrong. Do they live in a perfect world where nobody stores dates as ISO 8601 strings? I've seen that tons of times. Sometimes, it may even be considered the appropriate format when using stuff like JSON based formats.

[–] [email protected] 2 points 3 days ago (2 children)

I'm 100% with you - it's the dangerous level of knowledge where someone understands the technical background for the most part, but is lacking real world experience. Reminds me of the blog posts titled "Misconceptions programmers have about X" - almost everything we touch in IT is complicated if you get deep enough.

But their style of commenting really jives with Lemmy on technical topics. I can't count the number of posts where people proudly shout fundamentally wrong explanations for current AI models, yet any corrections are downvoted to oblivion. It's not as bad on non-AI-topics, but I can't imagine anyone in the field reading GPs comment and agreeing...

[–] [email protected] 1 points 3 days ago (1 children)

Jibes, not jives.

If you're jiving, you're dancing.

[–] [email protected] 1 points 3 days ago

Thanks for the correction, I didn't know that!

[–] [email protected] 1 points 3 days ago

This is why [email protected] is a thing.

[–] [email protected] -1 points 3 days ago (1 children)

I would hope that these kinds of parsers are not used in critical applications that could actually lead to catastrophic events, that's definitely different to Y2K. There would be bugs, yes, but quite fixable ones.

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.

"There's no glory in prevention". I guess it's hard to grasp nowadays, that mankind at some point actually tried to stop catastrophies from happening and succeeded

[–] [email protected] 5 points 3 days ago (1 children)

Even if such parsers aren't used directly in critical systems, they'll surely be used in the supply chains of critical systems. Your train won't randomly derail, but disruptions in the supply chain can cause repair parts not to be delivered, that kind of thing.

And you can be certain such parsers are used in almost every application dealing with datetimes that hasn't been specifically audited or secured. 99% of software is held together with duct tape.

[–] [email protected] 1 points 3 days ago (1 children)

True. But I wouldn't see this as extremely more critical than the hundreds of other issues we encounter daily in software. Tbh, I'd be glad if some of the software I have to use daily had more duct tape on it...

[–] [email protected] 4 points 3 days ago

I think you might be underestimating the potential impact.

Remember the Crowdstrike Windows BSOD? It caused billions in damages, and it's the absolute best case scenario for this kind of issue. Our potential Y10K bug has a bunch of additional issues:

  • you don't just have to patch one piece of software, but potentially all software ever written that's still in use, a bunch of which won't have active maintainers
  • hitting the bug won't necessarily cause crashes (which are easy to recognize), it can also lead to wrong behavior, which will take time to identify. Now imagine hundreds of companies hitting the bug in different environments, each with their own wrong behavior. Can you imagine the amount of continuous supply chain disruptions?
  • fixes have to be thought about and implemented per-application. There's no panacea, so it will be an incredible amount of work.

I really don't see how this scenario is comparable to anything we've faced, beyond Y2K.