5 ms·

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

LilBytes 4y ago
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... :-/
- pocketarc 4y ago
  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).
  - LilBytes 4y ago
    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.
    - nibbleshifter 4y ago
      > Out of support, aging 32bit SPARC hosts running 4.6c SAP. That's production!
  - Wevah 4y ago
    Some (many?) currently-updated 32-but OSS have been changed to use a 64-bit timestamp now, too.
  - iforgotpassword 4y ago
    Nah, just switch to unsigned 32bit, much easier fix and someone will probably have figured it all out until that becomes a problem! ;-)
  - wizofaus 4y ago
    Nothing wrong? You say that now, but just wait until the year 292277026596!
abnercoimbre 4y ago
Are there any good mitigation strategies published somewhere?
- bobsmooth 4y ago
  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.
  - mark-r 4y ago
    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.

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

pocketarc 4y ago
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).
- LilBytes 4y ago
  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.
  - nibbleshifter 4y ago
    > Out of support, aging 32bit SPARC hosts running 4.6c SAP. That's production!
- Wevah 4y ago
  Some (many?) currently-updated 32-but OSS have been changed to use a 64-bit timestamp now, too.
- iforgotpassword 4y ago
  Nah, just switch to unsigned 32bit, much easier fix and someone will probably have figured it all out until that becomes a problem! ;-)
- wizofaus 4y ago
  Nothing wrong? You say that now, but just wait until the year 292277026596!

abnercoimbre 4y ago

Are there any good mitigation strategies published somewhere?

bobsmooth 4y ago
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.
- mark-r 4y ago
  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.