The problem doesn’t concern me as much at how bad we’ve become at maintaining shit that already works.

There is also the fact that during Y2K, we didn’t have as much reliance on computers.

A 64-bit signed integer can represent timestamps far into the future—roughly 292 billion years in fact, which should cover us until well after the heat death of the universe. Until we discover a solution for that fundamental physical limit, we should be fine.

Come on now, heat death will take far more than 10¹⁰⁰ years, not just 3x10¹¹. It's not the point of the article but get your facts right.

I'm not too worried about the year 2038 problem. I suspect it will be similar to Y2K, with a bit of overhyped panic, but with most stuff being patched beforehand to avoid issues.

I was at Pepsi for Y2K. In 98, we started with MSMail, W95, and Netware2. We had to also replace all 40k desktops. We worked like dogs for those 2 years and only barely had everything ready in time. Without that work, we would not have been able to continue any business operations. Nothing about it was overhyped.

There was also a worldwide effort to fix any potential problems before they happened.

So the Steam client will have to be updated to 64-bit before 2038.

Issue 2038 will be easier to fix because many systems are already 64-bit, as 32-bit systems could only handle 4 GB of RAM, and programs need more RAM.

The only issue would be critical issues that run on 32-bit systems and must be fixed before that date.

MACs will have their Y2K in 2040

Y2K wasn’t overhyped. It was just successfully planned for. This reeks of the paradox of IT. “Everything is broken, what do you even do” vs “nothing is broken, what do you even do?”

Did you mean Media Access Controllers, or macOS?

Not really. 32-bit apps can use 64-bit values.

Cobol mavens burned both ends of the candle and made bank, while making banks work.

Many were old enough to retire after that.

32-bit systems could only handle 4 GB of RAM

I don’t understand why people always say that. Pentium Pro could handle 64 GB even though it was a 32 bit CPU. It had a 36 bit address bus. Later models are the same.

HFS has this limitation but isn’t the default file system anymore since several years ago.

So this is only a problem for 32-bit apps on 32-bit processors?

Linux kernel has had support for 64 bit time for years. On Debian, packages for the upcoming release were updated to 64 bit time earlier this year. I'm fairly sure the other distributions have done or are doing the same. So basically you now have 2 years to upgrade your OS and to pester the vendors of commercial software to do the same.

Like someone else said, it will be 2 very busy years, but we can survive this.

No, those can have 64 bit value as well, this is only a problem for applications which haven't switched to using them.

It only depends whether the app and its OS/kernel interface use a 32-bit value to store the time information.

32-bit architecture or OS has nothing to do with this bug, for example 16-bit architectures must've used 32-bit time, too (otherwise they'd be able to only count up to 32-65 seconds).

People say it because it was a Windows limitation, not a computing limitation. Windows Server had support for more, but for consumers, it wasn't easily doable. I believe there's modern workarounds though. The real limit is how much memory a single application can address at any given time.

The real problem is not avg Joe devices but things like banking mainframes tbh