[mlichvar]

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.

[_kst_]

> 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]

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]

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

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]

Fwiw, https://en.wikipedia.org/wiki/Perpetual_calendar