Hacker News Reader

Comment by thejosh | Hacker News Reader

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

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

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

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

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!

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.

Reply on news.ycombinator.com