Y2K was not a hoax. It was real, but it was (mostly) averted.

Bernard Salt writing in The Australian today implies that Y2K was a hoax:

Do you remember the Y2K bug, the computer programming flaw that threatened to reset the digital world to the year zero at the turn of the century? Hospital life support systems might stop. Planes might lose navigation. Everyone’s bank accounts might reset to zero.

The issue surfaced in popular culture in the mid-1990s; it reached fever pitch in the 12 months leading up to the new millennium. And then on New Year’s Day 2000 … nothing.

Phew, that was close. Just as well governments and big business invested millions if not billions in consulting advice to correct the situation. Here was a looming calamity that only geeks could understand. Our job was to comply and to pay up so as to avert disaster.

But I am of course being unfair to the peddlers of Y2K calamity — they were simply feeding the natural market for fear of the future. Why, no sooner had Y2K receded than the threat of pandemic via avian flu and then severe acute respiratory syndrome was scaring us witless. Same modus operandi as Y2K: credible narrative that only geeks can understand. It’s all so terribly empowering for geeks.

This gets my goat.

Y2K was very real. The effects were real, but mostly averted — precisely because it was taken seriously.

So what was the Y2K bug?

It’s not a problem that, as Mr Salt claims, only geeks can understand.

By the late 20th century, computerisation was becoming commonplace.

Because it was common for people to write years as two digits, and computer memory in the 70s and 80s was scarce, and forward planning wasn’t great, it became common to write computer programs to use two digit years; to assume that the year was 19xx.

By the late-1980s, it was clear that ticking over into the year 2000 would be a problem for those computer systems using two digit years. It was drummed into us when I started my IT degree in 1989 that many of these systems would still be around in the 21st century, and they had to be written to take dates beyond 1999 into account.

A simple example: To calculate how many years since one was born, calculate the Current Year minus Birth Year. For me in 1995, this was 95 – 70 = 25. Easy. But what happens in the year 2000? 00 – 70. Either the computer would stop with an error (software can be a bit delicate, and prone to just stopping if something unexpected happens) or it might conclude that my age is minus 70.

It was blindingly obvious that with so many systems out there at risk of not coping with the year 2000, something had to be done. It was widely recognised, and acted upon.

How to fix it

In many cases it wasn’t really known what would happen, so a lot of testing occurred to show which systems were Y2K compliant, and which were vulnerable.

If vulnerable, broadly, there were three ways of fixing it:

• Expand date fields to four digit years — complicated at times, and not always possible
• Put in logic that said anything between 00 and (say) 49 was to be treated as 20xx rather than 19xx — easier in some cases, but this would cause problems with birth dates in particular, for older people. It also means the problem isn’t really fixed, just deferred.
• Entirely replace/rewrite the software.

Of course any of these activities involves a lot of testing to make sure it all works.

How it played out

In the late 90s I worked at a company whose software was mostly written in the early-80s, running Point Of Sale and back-office operations for thousands of Australian service stations.

They considered rewriting their applications completely, which would have had the benefit of moving from old DOS/character-based interfaces to a more modern Windows graphical interface, but they are hugely complex applications, and there wasn’t time.

I worked for them writing Windows programs that replaced a small portion of their systems, but mostly they did a lot of work fixing their existing software instead. (As of 2015, they still haven’t been entirely re-written.)

Right across the IT world similar activity was happening. To their credit, big companies (often with the oldest, most trouble-prone systems) worked the hardest to avert a problem, knowing that if their computers fell over in January 2000, it could have significant economic impact.

Of course some people worked very hard to prevent issues, and of those, some made a lot of money in the process. (In Australia there was a mini-boom in IT at the time, was many programmers also worked on implementing the GST, which came in July 2000.)

A few (especially smaller) organisations largely ignored the Y2K problem, or just hoped it wouldn’t cause major issues. But most either replaced or fixed their systems.

Some put in operational precautions — for instance in Melbourne, the New Year’s Eve trains stopped for about 5 minutes around 1am on 1/1/2000 (because 1am Summer time is midnight Standard Time) for fear there could be power or other disruptions. (Spoiler: there weren’t.)

So what happened in 2000?

Despite some panic beforehand, most of the big and important systems kept working more-or-less to plan precisely because the problem had been recognised and acted upon.

But some systems either failed in non-critical ways, or produced slightly odd results. Here’s a documented minor example: in early 2000 I received an insurance renewal notice — from a small insurance broker — advising me to start paying from March 1900.

There were numerous other cases of date errors causing issues, for instance:

The only potentially worrying events occurred at nuclear power plants in Japan. Radiation-monitoring equipment in Ishikawa failed at midnight but officials said there was no risk to the public. Alarms had sounded at another plant at the same time but no problems were found. — BBC

But mostly the problems were only minor and/or amusing.

Could it happen again?

Individual computer systems have the potential for similar failures due to data fields overflowing. For instance a system that uses a unique number for each transaction but only allows ten digits could have problems after they tick over from transaction number 9,999,999,999.

Some systems track dates by seconds from a specific date, and those fields could overflow in the future — for instance on 19 January 2038, versions of Unix that use 32-bit time stamps will stop working.

It was real

In his opinion piece, Mr Salt appears to be playing to The Australian’s conservative audience. Although he doesn’t mention climate change, he seems to be saying that because we can’t see the effects of Y2K, swine flu or peak oil, none of them were or are real, basically saying we should dismiss any doomsayers who come along proclaiming there are big problems ahead.

The reality is we need to examine the evidence and be rational about it. Some problems are exaggerated, some are real.

Some were real and were avoided. Y2K was one of those. The problem was not conceptually complex; you don’t need an IT degree to understand that if nothing had been done, there could have been big problems.

Daniel Bowen
Bach. of Computing (Information Systems), Monash University, 1992.

• Quite a good list of Y2K failures from 1999… with a bunch of ill-informed “hoax!” comments at the bottom.
• “Disaster averted. … Y2K was boring because the period of time leading up to it was very non-boring.” — Raymond Chen