During restoration work on old systems, the British National Museum of Computing discovered an unexpected problem that could cause the Year 2038 bug to occur even earlier.
The Year 2038 problem, also known as Epochalypse, occurs in systems that store Unix time in a signed 32-bit integer. Unix time counts seconds from the epoch, which is January 1, 1970, at 00:00:00 UTC. On January 19, 2038, at 03:14:07 UTC, that counter will reach its maximum and overflow. In theory, this would result in a date from 1901, causing software and operating systems that still depend on 32-bit time structures to malfunction. Modern systems now use 64-bit. However, old infrastructure often remains in use longer than planned.
Volunteer Robin Downs demonstrated the problem to The Register in the museum’s Large Systems Gallery, which houses a working PDP-11/73. He pointed out that the software for this machine had already been modified in the 1990s to address the millennium problem (Y2K). According to him, the problem mainly revolved around programmers who only used two digits for the year.
According to Downs, the situation around 2038 is of a different order. Although the PDP-11/73 does not run Unix, the system does have a C compiler from 1982. This compiler appears to have several limitations. Downs noted that the compiler already returns an incorrect date when asked for the current date and time. The time is correct, but the date is not.
Initially, this seemed annoying but solvable, until he set the system clock forward. In a simulation in 2036, everything went well, but in 2037, things went wrong: programs that called the time function crashed immediately. Downs concluded that there is an unknown error in the compiler that causes problems a year before the expected Epochalypse.
Error in local time function
In his test, the system did not jump to 1901 as expected, but back to 1970. Downs explains that the local time function itself contains an error, jumping back 68 years instead of a negative value. According to him, this could mean that there are not only problems in the compiler, but also in the way software processes the date and how machines behave in practice.
Former Microsoft engineer Dave Plummer expects most issues to be resolved in time. He points out that processes running around 2038 are the most vulnerable, but that the coming years will likely provide sufficient opportunity to identify remaining dependencies.
Downs remains concerned, however. He points out that children visiting the museum today could start working as engineers in twelve or thirteen years’ time and then be confronted with old code full of pitfalls. During his work, he has already spoken to experienced C programmers who were unaware of the potential problems. Moreover, he believes that we are currently building systems that are designed to last more than ten years, which means that the risks remain real.