4 ms·

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

rbanffy 4y ago
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).
- andreareina 4y ago
  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?
  - mgerdts 4y ago
    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.
    - mark-r 4y ago
      The only manifestation of Y2K that I ever saw was a receipt with the date 1/2/100.
      - rbanffy 4y ago
        I saw that in websites with Perl-generated dates.
- pjc50 4y ago
  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.
  - rbanffy 4y ago
    True, but it's not like a birth date - this one goes very deep into the core of the operating system.
thejosh 4y ago
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! ;-)
jonny_eh 4y ago
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.
gnulinux 4y ago
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.
- iforgotpassword 4y ago
  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.
teawrecks 4y ago
Oh much better, for sure, it'll be so much worse...
chiph 4y ago
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.
- iso1631 4y ago
  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

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

andreareina 4y ago
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?
- mgerdts 4y ago
  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.
  - mark-r 4y ago
    The only manifestation of Y2K that I ever saw was a receipt with the date 1/2/100.
    - rbanffy 4y ago
      I saw that in websites with Perl-generated dates.
pjc50 4y ago
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.
- rbanffy 4y ago
  True, but it's not like a birth date - this one goes very deep into the core of the operating system.

thejosh 4y ago

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! ;-)

jonny_eh 4y ago

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.

gnulinux 4y ago

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.

iforgotpassword 4y ago
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.

teawrecks 4y ago

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

chiph 4y ago

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.

iso1631 4y ago
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