• AA5B@lemmy.world
    link
    fedilink
    arrow-up
    3
    ·
    10 hours ago

    It will be interesting to see that play out. The thing is the 238 prboem spas long been solved just like the y2k problem was.

    The Linux datetime types were moved to 64 bit values long ago, so this problem is thousands of years out. The old 32 bit values was a limitation of older systems not handling larger values, but almost all hardware today is either 64 bit or has hardware support for 64 bit data. You mainly have some older embedded systems

    But the legacy 32 bit APIs are still there so it doesn’t break backward compatibility. You have huge ecosystems of software that still use these APIs and may still handle datelines as 32bit. There’s no way to find them all, much less make sure they’ve been updated.

    Just like y2k, 2038 will have been a long solved issue, that may still exist due to ancient or poorly written applications. All you can do is a huge effort of trying everything to find any remaining issues before they cause problems. I’m optimistic because y2k was a problem cased by every application handling their own dates, whereas for 2038 its cause was in an underlying data type that has long since been fixed. Surely all applications will have been rebuilt to the new API in that 20 year or so period, right? Right?

    • Randelung@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      10 hours ago

      I expect governments to set up own time servers and reset it to 1970 before upgrading their old Win XP machines.