When the Internet Almost Broke, and Why It Might Be Happening Again
On September 6th, 1993, Peter de Jager published what would go on to become one of the most influential articles in the history of the internet. Cheerfully titled “Doomsday 2000”, it outlined the fear that worldwide infrastructure and online systems might crash, coined “Y2K”. Mass hysteria followed, so much so that by 2000, the global economy had put a combined $300-$600 billion dollars towards resolving it, and thankfully the glitch passed with only minor technicalities. But that may not be the end of older tech threatening to crash more modern systems, as in 2038, it’s possible that there might be a second coming of the Y2K crisis.
Let’s start with the beginning. Memory storage in early programming was extremely expensive, so programmers often typed the last two digits of years (e.g. ‘99’ to represent ‘1999’) in order to save budget. However, this caused widespread fear that when the millennia turned, computers would interpret the ‘00’ as 1900 instead of 2000, which would lead to widespread malfunctions. Any software that relied on date logic, or sorting, such as loan maturation and interest calculations would be hit with problems, causing potentially catastrophic problems like incorrect interest charges and pension payouts. This was further fuelled by sensationalist journalism predicting TEOTWAWKI (The End Of The World As We Know It). Yet the public believed it, with over 59% ‘worried’ about the issue by 1998. Indeed, many people, like the California programmer Scott Olmstead, stocked up on food, safe haven assets like gold, and even guns and a bunker to prepare for the seeming Armageddon. In an interview with NPR Olmstead said that he would be ready: "Whatever it is, if we want to 'bug out,' as the programmers say, we can do it. We've got a place to go."
Yet nothing failed to materialize. Why? Nowadays, Y2K is treated like a joke, considered a hoax of the programming world, although it actually took billions of dollars and hours of manpower to fix it, because replacing every two-digit year field with a four-digit year (known as expansion) was far too slow and expensive to pull off before the millennium, engineers relied on an arsenal of clever workarounds. The primary tactical weapon was data windowing which is a programming shortcut that taught legacy systems to interpret two-digit years based on a point. For example, if a program saw a year lower than 30, it assumed the 2000s, while anything 30 or higher defaulted to the 1900s. Where code was too fragile to alter, developers built custom bridge software to intercept dates on the fly, patched machine code directly, or used binary compression tricks to fit extra data into tight single-byte slots. Millions of lines of forgotten COBOL (Common Business-Oriented Language) code were unearthed and manually audited. Ultimately, through an unprecedented mix of global coordination, brilliant hacks, and massive financial backing, the crisis was averted, rendering the world's biggest software overhaul so seamless that the public mistook it for a false alarm.
Executives also took an opportunity to line their own pockets in the midst of the panic, however, by clamouring for higher funding for the prevention efforts, they could enact sweeping upgrades and changes that had nothing to do with the date problem, boosting their own pay check in the process. As Mark Manion put it in his ScienceDirect article about responsibility “"Despite the dedicated efforts of IT professionals, as well as all of the resources devoted to the problem, the Y2K problem has produced an obvious failure of technology management on the part of corporate executives, and a failure of professional responsibility on the part of IT professionals."
This was the first Y2K crisis, and it helps explain why the technology sector is genuinely worried about the next date-based software vulnerability, Y2K38.
If someone told you they were 1790704964 seconds old, you might think they were a bit strange, or probably never talk to them again. But this number represents an important concept in how computers are programmed.
Due to early limits in storage, developers could only represent time up until a certain point in the future, so they picked a convenient date to measure from (1st Jan 1970, 00:00). This is what’s called Unix (Unix being the early operating system which gave inspiration to MacOS and Linux) time and is how your phone measures what time it is. But there is a slight problem. Due to the lack of computer development at that point, data was stored on 32-bit signed integers, which are data types storing values from ~2bn to -2bn. This imposes an upper limit on the amount of time which can be stored on these, specifically January 19th, 2038, at 03:14:07 UTC. When it ticks one second past the limit, any system which runs on Unix systems will experience an integer overflow (basically reset to -2bn), which will mean that time will be registered as Friday December 13th, 1901. Additionally, this issue is already causing some developers problems. As software engineer Jan-Kees Van Andel put it "The Y2K38 problem will be giving us headaches long, long before 2038 arrives... The problem is not limited to current date ≥2038. The problem will also occur whenever time_t needs to represent a date ≥2038"1. So, any contract or transaction where it deals with dates past 2038 is already experiencing trouble.
Any critical infrastructure, like power stations that runs on 32-bit will experience crashes and problems, financial mechanisms like interest calculations from mortgage loans expiring after 2038 could yield negative monthly interest, and authentication like OAuth and JWT could fail, leading to API blockages and microservice authentication delays, which could pose dangers to critical infrastructure.
However, not all is lost. Linux migrated all its time to 64-bit integers long ago, (which have 292 billion years of Unix time left on them), which negates the 2038 problem, and systems like windows and macOS have already switched entirely to 64-bit. However, developing nations and places with fewer government subsidies will struggle, and could face significant problems in communications, supply chains and financial systems. Although efforts are being made to update software, lots of Internet of Things (Iot) objects (physical devices that use sensors to measure data like temperature) can’t be auto updated, and many manufacturers will not support those products by 2038, leading to breakdowns in archaic smart meters, and heating systems.
In the end, the thread connecting Y2K and Y2K38 reveals that both are less about sudden, unpredictable technological catastrophes than recurring systemic failures, born from decades of corporate shortsightedness, unmanaged technical debt, and deferred engineering responsibility, and we have to hope that the repercussions wont be too serious this time.
Bibliography
Manion, Mark. "The Y2K problem and professional responsibility: a retrospective analysis." ScienceDirect, 18 Aug. 2000,www.sciencedirect.com/science/article/pii/S0160791X00000154. Van
Andel, Jan-Kees. "@jxf.me (Bluesky) / Jxf@mastodon.social (Mastodon) (@jxxf) on X." X (formerly Twitter), 19 Jan. 2020, x.com/jxxf/status/1219009308438024200.