A possible issue I thought up in the last few days:
Most large servers, phones, etc. are running Unix-based systems, and in Unix, time is counted as how many seconds have gone by since January 1st, 1970. Software was written in the 1970s and 1980s during a time of rapid technological development, so programmers thought that their programs wouldn’t be used for very long before they would be replaced by newer and better programs running on much more capable machines. So they just stored the date in two digits rather than four. But suddenly innovations in a lot of areas slowed down, and software was used for much longer. That’s why humanity suddenly ran into the Y2K problem — the issue that software couldn’t handle having the current year expressed in two digits be lower than the previous year.
There was a lot of talk about this in the years leading up to the year 2000, and many software experts had to do last-minute updates and monitor systems to make sure everything could survive the millennium shift. Luckily, with a few exceptions, nothing much happened.
Now imagine this: What if some of the problems from back then return in the year 2030? Let’s just imagine the following: A nuclear power plant somewhere has software that records the temperature of a substance in some container and saves the reading into a database tagged with a date. Another software, or another part of the software, then accesses the database, finds the last reading based on the date, and does something based on this reading — opens a valve or closes one, etc.
What would have happened on the night of December 31st, 1999? The last reading of the year 1999 would have the date “99-12-31 23:XX:XX,” which would be higher than any subsequent reading, which would all be tagged with a timestamp “00-01-01 XX:XX:XX.” So the second part of the program would continue to act upon the last reading from the year 1999 rather than the most current reading. Maybe that would have been fine five or ten minutes past midnight when the temperature hadn’t changed much, but it could have given catastrophic results hours later when the valve had been open or shut for hours without reacting to any temperature changes.
Luckily, lots of Y2K experts were employed back then to prevent disaster. So what action could a software expert noticing this issue that night have taken? Hopefully they found the source code of the program in question to handle four-digit dates, and the issue was over. But time was scarce that night, and there were parties to attend as well. Also, a lot of those old devices simply lacked the hardware capabilities to spend extra storage space on such long dates.
For those reasons, it is not impossible to think that at least in some places experts would have chosen a simpler solution: simply reset the clock to zero — January 1st, 1970. In many cases, that would have solved the issue immediately. Historic values would not be comparable, but those may not have mattered much anyway a few minutes past midnight.
If the programmer in question was 35 years old, this may have looked like a permanent solution. When the boss complained on January 2nd, 2000, that the dates in the status reports looked funny, the Y2K expert may just have changed the code creating the status reports to add 30 to the year. By the time this Y2K expert goes into retirement sometime in the 2020s, the issue from back then has been long forgotten about… except the issue comes back on January 1st, 2030. And at that time, no one is paying Y2K experts to do night shifts.
PS: An AI assistant that I consulted about this would like to point out that “resetting the clock to 1970” was not a typical fix for the Y2K problem. Instead, systems were typically reprogrammed to interpret numbers below 30 as belonging to the 21st century and numbers 30 and above as belonging to the 20th century — a technique called “date windowing” or using a “pivot year.” This means that if any of those systems are still running today, they will hit their real expiration date in 2030, when the year “30” suddenly gets sorted into 1930 instead of 2030. So while my Unix-epoch-reset scenario above is purely a thought experiment, the underlying danger is real — just via a different, equally boring bureaucratic mechanism.
The AI assistant also insists that I mention the actual Unix time bomb, which is the Year 2038 problem. On January 19th, 2038, at 03:14:07 UTC, 32-bit Unix systems will run out of seconds to count and the date will jump back to 1901. This has nothing to do with two-digit years and everything to do with the fact that a signed 32-bit integer can only hold about 2.1 billion seconds. So if your phone, server, or embedded device is still running 32-bit Unix code in 2038, it won’t need a creative Y2K workaround to break — it will break all on its own, with no imagination required.
Leave a Reply