I think a lot of systems, a lot of them embedded, will fail in odd ways. Y2K was mostly a data format issue. This is much more interesting (and widespread).
BCD could be one of many problems, but ASCII strings would me more common in systems I dealt with. There were a lot of assumptions about two digit years that maybe made sense sometime in the 70s for code that you didn’t think would survive more than a few years.
Also take a look at struct tm. Its tm_year looked like just a 2 digit year and as such people may format it with printf(“19%02d”,…). It is actually the number of years since 1900. In early 2000 I had to fix a broken ftp server that was sending 19100 as the year.
I think it's likely to be better handled, but at the same time people keep citing the non-disaster of Y2K as a reason not to do disaster preparation, so I don't know.
My sense is that it'll be a lot worse, Y2K was only a data format issue, whereas 2038 issue has to do more with underlying hardware. It really all depends, and we'll see. Certainly, many old software will stop working in 2038.
I'd say both are a data format issue, y2k was usually at a higher level and occured in custom data formats of individual software, while 2038 is in the OS and basic libraries, or even in hardware.
I do think though there were some bioses that messed it up too, so that's rather low level too.
For systems running in finance, the problem should have already shown up when calculating dates for 30 year bonds and mortgages. But as another poster said, there's a ton of embedded systems out there running Linux that likely aren't handling it correctly.
In spite of knowing about this issue in 2038, registering a lot of domains to the affect and hoping I can burst out a lot of contracting work that year, make bank and retire.
I’m assuming by EPOC you’re talking about Unix timestamps? There’s nothing wrong with them if they’re 64-bit.
As I understand it, it seems like it’s mostly software using 32-bit integers that will struggle.
So if you’re writing modern code on a modern runtime running on 64-bit platforms you should be fine (easy to verify by changing your dev environment’s clock).
I kid, fixing this will require an even greater amount of effort compared to the Y2K bug considering how many more linux devices have been deployed since then.
Consider how many of those linux devices are difficult or impossible to update, and you start to realize the mess we'll be in. At least Y2K affected systems that by and large could be updated easily.
It all depends. We have more devices and software now, but a lot more critical stuff is centrally hosted by cloud providers that'll be ready long before the deadline.