[Waterluvian]

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.

[teddyh]

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

[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?

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

https://github.com/wolfcw/libfaketime

[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

[jmbwell]

It was pretty easy for orgs with affected systems to produce concrete examples for themselves. Maybe to everyone else it seemed vague, but for the people who had to deal with it, it was taken pretty seriously from top to bottom.

It was thankless work that is still glossed over and waved away today, but it was all a very big deal throughout the late 90s.

[mulmen]

> It was thankless work that is still glossed over and waved away today, but it was all a very big deal throughout the late 90s.

Mike Judge even made a movie about it! Office Space might be the most recognition turn of the millennium programmers will receive.

[Waterluvian]

All I can say is that at my level in an org, if I want to say “instead of developing X this quarter, I want to test the effects of 2038 on Y,” that’s a far easier conversation if I can say something like “in similar embedded devices they crashed and wouldn’t even respond to OTA updates” vs “something bad could happen. Not sure.”

The latter is just a ripe plumb, left to rot in the backlog.

[bongodongobob]

That's nonsense. Orgs spent time and resources on it because they grabbed a test server and demonstrated it caused problems. It's not some weird ethereal untestable bug. They set the dev server to a minute before midnight and went "oh shit".

[pixl97]

That and quite often the problems started showing up years before 2000 itself. "Hey, the scheduler is giving me a meeting 80 years ago" type weirdness when it crossed the boundry.

[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?

[LargoLasskhyfv]

Why not? From five years ago, on the most modern type:

https://www.theregister.com/2020/04/02/boeing_787_power_cycl...

Seems to be unrelated at first look, but considering the complexities of systems, and cascading failure modes?