At the turn of the year 1999/2000, there were dystopian predictions, from the failure of computer systems to the false starts of nuclear weapons systems. The reason for this was the bug known as the Millennium Bug or Y2K Bug – And in 2038, a related problem awaits us in the form of the Y2K38 Bug.
What is the millennium bug?
Nowadays, storage space is becoming cheaper and cheaper and hard drives are getting bigger and bigger. But that wasn’t always the case; in the 60s and 70s, people fought over every single bit. If a date was stored, it was very easy to save two memory locations – by omitting the hundreds and thousands digits of a year number. The year 1960 was thus stored as “60” and the interpretation automatically assumed that it was the 20th century. No consideration was given to the fact that the programs could have a lifetime extending beyond the millennium. At the turn of the year 1999/2000, the year number now jumped from “99”, which was interpreted as 1999, to “00”, which was often interpreted as “1900”. Fixing this error before the turn of the year cost billions. As the SPIEGEL reported in an article about the missing apocalypse of the Y2K bug, this error caused, for example, tax claims to be calculated incorrectly and a US American received a tax claim over the last 100 years.
The cause of the Y2K38 bug
The fundamental problem of the Y2K38 bug is based on the representations that computers use for time information. For this purpose, the time is counted from a fixed defined point and stored as a binary number. Common for this is the Unix time, which counts the seconds since January 1, 1970 00:00 UTC. At least 32 digits of a binary number must be available for the counted seconds. Potentially 2^32 seconds (approx. 136 years) are representable. However, Unix time uses the first of the 32 digits as a sign and can thus represent ± 2^31 seconds (about 68 years) from 1970. And that’s exactly what becomes a problem with Y2K38.
Especially on older systems the Unix time is represented with 32 bits. If the above-mentioned 68 years are now exceeded, a so-called arithmetic overflow occurs. This overflow is the Y2K38 error. Instead of continuing to count up, the first digit of the 32-character binary number jumps from “0” to “1”. But since this digit indicates whether the number is positive or negative, the date jumps back abruptly by about 136 years. At 03:14:07 on January 19, 2038, the jump follows to 20:45:52 on December 13, 1901. The animation shown below represents the overflow.
The effects of the Y2K38 bug
Operating systems based on the Unix era are often used by servers or embedded systems such as routers or measuring devices. Since servers in particular are usually operated much longer than home computers, it cannot be ruled out that programs or low-powered electrical devices that calculate with 32 bits output incorrect displays or have malfunctions. Considering how many devices now have their own processor and are integrated into our everyday lives, it is very difficult to predict how many of these will have been checked for vulnerability to the Y2K38 bug by the year 2038. As a company, you should budget accordingly for the long term in order to find the error early on.
To fix the Y2K38 bug, it is not enough to simply use a new device with 64 digits to the clock and reload the old software or firmware. It is possible that the use of a maximum of 32 digits has been written hard into the software and does not make use of additional available digits. Therefore, the software has to be checked and, if necessary, adapted before it is played on a device with 64-bit architecture – a considerable effort. Especially for systems that are permanently installed and cannot be easily adapted, troubleshooting is difficult.
Conclusion
It is virtually impossible to predict exactly how the Y2K38 bug will affect systems. Even if a system computes in 32 bits, it does not automatically follow that functionality is limited. It is also conceivable that only display errors occur, which have no effect on the further function of the software. Fortunately, unlike zero-day exploits, one has lead time and it is known exactly at what time the bug will occur. If the error is treated as a serious problem and the company’s own systems are checked accordingly, the impact can be significantly reduced.
