Hacker News Reader

Comment by houstonn | Hacker News Reader

How will this stack up compared to the Year 2000 bug? Better? Worse?

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

Wasn't the y2k issue programs that stored numbers as binary coded decimal and only allocated one octet (i.e. two digits) to the date?

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.

The only manifestation of Y2K that I ever saw was a receipt with the date 1/2/100.

I saw that in websites with Perl-generated dates.

Y2038 is also a data format issue (32-bit dates).

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.

True, but it's not like a birth date - this one goes very deep into the core of the operating system.

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.

Those 30 years bonds would have been opened in 2008, about the time of the last recession.

Total coincidence, but fun to think of the conspiracy theory :D

Considering the amount of devices we have now, and the devices and applications we'll have in 16 years..

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 use EPOC time in my own code NOW, a lot... :-/

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

On recollection there's definitely a non-zero number of 32 bit machines I worked on up until I quit my last job.

Out of support, aging 32bit SPARC hosts running 4.6c SAP.

> Out of support, aging 32bit SPARC hosts running 4.6c SAP.

That's production!

Some (many?) currently-updated 32-but OSS have been changed to use a 64-bit timestamp now, too.

Nah, just switch to unsigned 32bit, much easier fix and someone will probably have figured it all out until that becomes a problem! ;-)

Nothing wrong? You say that now, but just wait until the year 292277026596!

Are there any good mitigation strategies published somewhere?

find "int32"

replace "int64"

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.

Oh much better, for sure, it'll be so much worse...

Reply on news.ycombinator.com