Y2K and 2038 Problems
Discussions affirm the reality of the Y2K bug and the massive efforts to fix it, while highlighting the upcoming Year 2038 problem as a similar time_t overflow issue in 32-bit systems.
Activity Over Time
Top Contributors
Keywords
Sample Comments
I just want to pile on here. Y2K was avoided due to a Herculean effort across the world to update systems. It was not an imaginary problem. You'll see it again in the lead up to 2038 [0].[0]: https://en.wikipedia.org/wiki/Year_2038_problem
Y2K was a real (potential) problem which didn't have consequences because a bunch of people did a bunch of work to avoid it.To give a brief description, dates were commonly stored with two digits for the year to save on disk space because the "19" prefix was assumed. Once 2000 got closer people started to realize this mistake. More similar to what will likely (and "suddenly") be big news around the mid 2030s: <a href="https://en.wikipedia.org/wiki/
ah interesting I hadn't realized. but for sure lots of problems will start occurring starting 2038
Fun fact: Y2K is still an issue in some old systems. Some, instead of going through and properly fixing the whole system, just bolted on logic to assume if the 2 digit year is less than say 30, assume it's 20xx and if it's 30 or more, assume it's 19xx. This saved the time of having to update the storage layer, but it means that they're in for a surprise in the future. Then there's the 2038 problem.
You'd think, but I worked at a bank in the early 2000s. Some companies got lazy and shifted the problem forward a few decades rather than actually fixing the problem.Y2K is still an issue in some places. Without knowing more, it's possible that this could be a really bad move. Or maybe it's fine. It depends on the state of their code, which I'm not familiar with.
That's how we ended up with the 2038 problem!
Given that most people don't know that the Y2K bug was real, I feel that this is a category of bug that will plague us forever. And it's already happening more often than once per century.https://en.wikipedia.org/wiki/Year_2038_problem
Yeah it's mostly a reference to Y2K and Y2038 [1], using representations that seem clever and work now, but will lead to bugs in the future because nobody thinks their software will be around for that long.[1] https://en.wikipedia.org/wiki/Year_2038_problem> The latest time since 1 January 1970 that can be stored using a signed 32-bit integer is 03:14:07 on Tuesday,
Closing in on the Y2K38 problem.
I remember times of y2k and thinking both how 2038 is far away and that none of the system we use will be there :) 13 years later (1/3 of the time) I'm not longer that sure...