3 ms·

The article missed an opportunity to describe how spectacularly can things break when the 32-bit time_t overflows in Y2038. If you still have such a machine (p

The article missed an opportunity to describe how spectacularly can things break when the 32-bit time_t overflows in Y2038. If you still have such a machine (preferably without any valuable data), try setting the date right before the overflow with this command date -s @$[2**31 - 10] and see if you can recover the system without reboot. I have seen different daemons stopped responding and just consuming CPU, NTP clients flooding public servers, and other interesting things. I suspect many of these systems will still be running in Y2038 and that day the Internet might break.

wongarsu 4y ago
Factories are full with machines that get replaced every couple decades, and that run software setups even older. Roughly a decade ago I was involved in the development of an embedded system for industrial use, and the approach to Y2038 was "doesn't matter, I'll be retired by then". The system is still sold. I wouldn't be surprised if a lot of companies will handle it by just setting the clocks back 50 years or so on industrial equipment. But God have mercy on those that forget some systems.
- mjevans 4y ago
  Most of these systems probably don't even care about the real time... so it'd just be more effective to map them back to a different index and handle it with an offset externally. https://en.wikipedia.org/wiki/Doomsday_rule https://en.wikipedia.org/wiki/Doomsday_rule At a glance it looks like 1971 and 1993 might be good alternatives for 2038. The command line cal program agrees with where dates start each month for all three years.
  - masklinn 4y ago
    Fwiw, https://en.wikipedia.org/wiki/Perpetual_calendar https://en.wikipedia.org/wiki/Perpetual_calendar
_kst_ 4y ago
> date -s @$[2*31 - 10] A digression: The documented bash syntax for arithmetic expansion is $(( EXPRESSION )) . I see that $[ EXPRESSION ] also works, but I don't see it documented anywhere. (Both syntaxes also work in zsh.)

wongarsu 4y ago

Factories are full with machines that get replaced every couple decades, and that run software setups even older. Roughly a decade ago I was involved in the development of an embedded system for industrial use, and the approach to Y2038 was "doesn't matter, I'll be retired by then". The system is still sold. I wouldn't be surprised if a lot of companies will handle it by just setting the clocks back 50 years or so on industrial equipment. But God have mercy on those that forget some systems.

mjevans 4y ago
Most of these systems probably don't even care about the real time... so it'd just be more effective to map them back to a different index and handle it with an offset externally. https://en.wikipedia.org/wiki/Doomsday_rule https://en.wikipedia.org/wiki/Doomsday_rule At a glance it looks like 1971 and 1993 might be good alternatives for 2038. The command line cal program agrees with where dates start each month for all three years.
- masklinn 4y ago
  Fwiw, https://en.wikipedia.org/wiki/Perpetual_calendar https://en.wikipedia.org/wiki/Perpetual_calendar

_kst_ 4y ago

> date -s @$[2*31 - 10] A digression: The documented bash syntax for arithmetic expansion is $(( EXPRESSION )) . I see that $[ EXPRESSION ] also works, but I don't see it documented anywhere. (Both syntaxes also work in zsh.)