Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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


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.


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.





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: