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.

📉 Falling 0.4x DevOps & Infrastructure
1,828
Comments
19
Years Active
5
Top Authors
#3066
Topic ID

Activity Over Time

2008
7
2009
31
2010
24
2011
29
2012
46
2013
49
2014
63
2015
32
2016
71
2017
138
2018
56
2019
128
2020
302
2021
120
2022
213
2023
154
2024
223
2025
137
2026
5

Keywords

MS IT Y10K AC Y2KKK92 MM arstechnica.com YY en.m YYYY dates date prefix ac year 1900 microwave fixed code bytes

Sample Comments

jmholla Mar 12, 2025 View on HN

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/

high_byte Dec 29, 2021 View on HN

ah interesting I hadn't realized. but for sure lots of problems will start occurring starting 2038

JohnTHaller Jun 15, 2017 View on HN

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.

actsasbuffoon Jun 15, 2017 View on HN

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.

freeone3000 Jan 14, 2021 View on HN

That's how we ended up with the 2038 problem!

nyghtly Jul 6, 2021 View on HN

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

cdirkx Apr 24, 2021 View on HN

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,

jl6 Oct 24, 2022 View on HN

Closing in on the Y2K38 problem.

radimm May 2, 2013 View on HN

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