"The machine's software had already been patched for the Y2K problem, where using two digits to store the year caused headaches when the century rolled around. "Y2K", Downs explained, "was mainly an application programming issue ... mostly it was application programmers not taking into account two digits." The Year 2038 problem is a different beast. Indicating the PDP-11/73, Downs said, "This machine isn't running Unix, but we have a C compiler on it, and the C compiler is from 1982, so it has ... various issues.""
""So, the C compiler on this, already now, when you ask it what the time and date are, it gets it wrong. It returns the correct time, but the wrong date." Annoying, but solvable. The team worked around the issue. However, when Downs was testing it by moving the system clock forward, something unexpected happened. He moved the clock forward to 2036, and everything seemed fine. Then, in 2037 - a year before the Epochalypse is due - the program crashed. "It turns out," said Downs, "the time function has another bug. Undocumented, unknown, where at the start of 2037, any program that calls the time function just crashes.""
Restorers at a computing museum encountered a pre-2038 time-related failure while running a PDP-11/73. The machine had been patched for Y2K, but its 1982-era C compiler and differing internal time structures produced incorrect dates while reporting correct times. The team implemented a workaround, but testing by advancing the system clock revealed a new failure: moving the clock to 2036 worked, but at the start of 2037 any program calling the time function crashed due to an undocumented bug. The discovery shows that legacy systems and old toolchains can contain hidden, pre-2038 faults that trigger crashes before the Year 2038 boundary.
Read at Theregister
Unable to calculate read time
Collection
[
|
...
]