The Unix Epochalypse Might be Sooner Than You Think
hubie writes:
Museum boffins find code that crashes in 2037:
A stark warning about the upcoming Epochalypse, also known as the "Year 2038 problem," has come from the past, as National Museum Of Computing system restorers have discovered an unsetting issue while working on ancient systems.
Robin Downs, a volunteer who was recently involved in an exhibition of Digital Equipment Corporation (DEC) gear at the museum, was on hand to demonstrate the problem to The Register in the museum's Large Systems Gallery, which now houses a running PDP-11/73.
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."
According to Downs, the operating system was patched for Y2K in the late 1990s, but doesn't use the same time structure for its internal date and time.
"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."
"So we found bugs that exist, pre-2038, in writing this that we didn't know about."
The Year 2038 problem occurs in systems that store Unix time - the number of seconds since the Unix epoch (00:00:00 UTC on January 1, 1970) in a signed 32-bit integer (64-bit is one modern approach, but legacy systems have a habit of lingering).
At 03:14:07 UTC on January 19, 2038, the second counter will overflow. In theory, this will result in a time and date being returned before the epoch - 20:45:52 UTC on December 13, 1901, but that didn't happen for Downs.
He said, "What we expected was that the local time function should return 1901. That's what we thought would happen."
Instead, it went back to 1970.
[...] Former Microsoft engineer Dave Plummer is optimistic that the problem will be solved in time. He told The Register, "Since the counter starts from current time, anything that is running when it rolls over in 2038 will be suspect. ie: it doesn't have to have been running for long.
"While it's conceivable there are important things that still rely on GetTickCount() or similar, I'd wager the intervening 13 years will be enough to find them!"
Read more of this story at SoylentNews.