What Was Y2K? The $100 Billion Bug That Was Either Averted or Imaginary
Two digits.
That is the entire bug. For decades, computer systems stored the year as two digits instead of four — 99 rather than 1999 — with the 19 silently assumed. On 1 January 2000 the assumption stopped being true, and a very large amount of the world's software was about to conclude it was 1900.
People remember Y2K as a joke that did not land. Bunkers, canned food, a lot of shouting, and then the ball dropped and nothing happened. What almost nobody remembers is the four years and roughly $100 billion of work that sat between the panic and the nothing — or that we still cannot prove which of those two things caused the quiet.
Why would anyone store a year in two digits?
Because memory used to cost an amount of money that is difficult to hold in your head now.
The Library of Congress puts the cost of a megabyte of memory in 1970 at more than $3,000,000. At that price, storing a date as MMDDYY instead of MMDDYYYY saved two bytes per record, and two bytes per record across millions of records across thousands of systems was not a rounding error. It was a line item that got signed off.
The Senate committee that later investigated it described the two-digit year as "a short-term solution to the oppressively high cost of computer memory in the 1950s and 1960s."
It was a good decision. It was correct at the time, made by competent people, and it worked for thirty years. The problem was never the trade-off. The problem was that the code outlived every assumption anyone had made about how long it would run.
Somebody warned them. In the sixties.
Bob Bemer — who worked on COBOL, contributed to ASCII and gave the world the Escape key — was lobbying US government agencies to require four-digit years in the 1960s. He was still at it in February 1979, writing in Interface Age: "There are many horror stories about programs, working for years, that died on some significant change in the date."
Nobody did much. There is nothing mysterious about why. A problem arriving in thirty years, in systems you personally will not be maintaining, is not a problem. It is somebody else's problem, and it stayed somebody else's problem right up until it wasn't.
The name arrived late. "Y2K" was coined by a Massachusetts programmer called David Eddy on 12 June 1995, in an email to a discussion group. Before that people were calling it the Century Date Change, or CDC, or — briefly and unfortunately — "Faddle," for Faulty Date Logic. Eddy's own explanation for why his version won: "It just came off my fingertips."
What $100 billion actually bought
The US Department of Commerce estimated in November 1999 that cumulative US Y2K spending was "in the neighborhood of $100 billion, or about $365 per U.S. resident," starting around 1995 and peaking in 1998 and 1999 at roughly $30 billion a year.
The report was honest about its own limits, which is more than most of the people quoting it have been. Its stated range: "we are confident that spending will total at least $50 billion and that it is unlikely that it will be higher than $150 billion." Separating Y2K work from routine maintenance, it noted, is genuinely difficult.
Global figures were never reconciled at all. Estimates run from about $320 billion to $500 billion, and there is no methodology behind any of them worth defending.
What the money bought was people reading code. Retired COBOL programmers were hired back at consulting rates to work on systems older than most of the engineers maintaining them. There were two ways to fix a date field:
Date expansion — widen the field to four digits and fix every program that touches it. Permanent, correct, expensive, and it means changing the data itself everywhere it lives.
Windowing — leave the two digits alone and add a rule: below some pivot year, assume 20xx; at or above it, assume 19xx. Cheap, fast, and it does not solve the problem. It moves it.
A great deal of windowing was done, because it was affordable, and 20 was a popular pivot. Which means a system windowed at 20 read the year 20, in the year 2020, as 1920. Y2K did not end on 1 January 2000 for those systems. It just came due again, more quietly, on a schedule set by whoever picked the pivot.
So did anything actually break?
Yes. Less than advertised, more than the folklore admits, and the documented cases are far more interesting than the imagined ones.
The US Naval Observatory — the office that keeps the country's official time — ran a millennium countdown page that displayed the date as "January 1, 19100" for roughly forty-five minutes after midnight. A Navy spokesman explained it as "an old computer programme that was not Y2K compliant" running on an outside web host. The master clock itself was fine. Only the website embarrassed itself, which is the most 1999 sentence available.
The Department of Defense lost the use of a satellite-based intelligence system. The GAO recorded that it "experienced a Y2K failure shortly after the rollover of Greenwich Mean Time" and that DoD could not process information from it.
Medicare contractors received at least 50,475 claims bearing service dates of 1900 or 2099.
The FAA saw low-level wind shear alert systems throw errors at eight sites, and a weather display system report the year as 2010.
And the most serious case did not surface for eighteen months. At the Northern General Hospital in Sheffield, a pathology system serving nine hospitals miscalculated the ages of pregnant women after the rollover, producing incorrect Down's syndrome screening results between January and May 2000. More than 150 women received wrong risk assessments. Four gave birth to babies with Down's syndrome after being told their risk was low. Two terminated pregnancies.
That is what a date bug looks like when it reaches all the way through to a person. It is worth remembering when Y2K comes up as a punchline.
What the "19100" actually is
It is not a maths error. It is a string error, and the distinction is the joke.
In C, and in the JavaScript that inherited the convention, the year is stored as the number of years since 1900. In 1999 that value is 99. In 2000 it is 100. The value is correct. It was always correct.
The bug is in code that built the year for display by gluing the literal text "19" onto the front of it. In 1999 that produces "1999" and looks like it works. In 2000 it produces "19100".
Which is why this particular failure showed up on websites, receipts and report headers rather than inside banking engines: it was a presentation bug, sitting in the last inch of the system, in code somebody wrote quickly because it was only printing a date.
Was the whole thing overblown?
This is the genuinely unresolved question, and anyone who tells you it is settled is arguing rather than reporting.
The case that the money was necessary. The Senate committee's formal judgment was that "the level of effort was justified and the expenditure of funds was indeed necessary." By December 1999, 99.9% of US federal mission-critical systems had been remediated — the quiet night is evidence the work landed. John Koskinen, who coordinated the US response, made the argument from revealed preference: "Industries and companies don't spend $100 billion dollars or devote these personnel resources to a problem they think is not serious." He also flew on a commercial aircraft on the night of 31 December 1999, and noted that had he not believed the work was done, he would not have. And the Sheffield screening failures, the DoD satellite, and fifty thousand mangled Medicare claims are proof the defect was real wherever remediation missed.
The case that it was overstated. The economist John Quiggin has made the strongest version of this argument, and it is not easily dismissed. Italy — an OECD economy, thoroughly computerised — confined remediation to critical systems and spent a fraction per capita of what the US did. Large parts of Eastern Europe and the developing world ignored the problem almost entirely. None of them suffered the cascading failures that were predicted. Quiggin also notes that fiscal-year rollovers during 1999 passed uneventfully even at poorly prepared organisations, which was an empirical signal available before the money was spent, and argues a cheaper "fix on failure" strategy was defensible. The Senate committee itself conceded, in its own report, that "the low level of disruption internationally was somewhat surprising."
The honest position is that this cannot be settled. A quiet rollover is exactly what you would observe if the remediation worked, and exactly what you would observe if the risk was overstated. There was one run of the experiment and no control group. Both readings survive the evidence, and that is not a failure of analysis — it is the shape of the problem.
It is going to happen again, on a schedule
Y2K was a convention problem. Humans decided to imply the "19" and humans could un-decide it.
Y2038 is a type problem, which is worse. Unix-derived systems count time as seconds elapsed since 1 January 1970, stored on 32-bit systems in a signed integer. That integer runs out at 03:14:07 UTC on 19 January 2038. One second later it overflows to negative and the machine believes it is December 1901. No convention can be renegotiated; the container is simply too small. The fix is 64-bit time, which pushes the limit out roughly 292 billion years. The exposure is in embedded and long-lived systems — which is precisely the profile of the COBOL estate that made Y2K expensive in the first place.
There is already a track record. GPS broadcasts its week number in a ten-bit field, so it wraps every 1,024 weeks. It rolled over in August 1999 — a dress rehearsal, four months before Y2K, that hardly anyone noticed — and again on 6 April 2019, when devices that had not accounted for it failed, some of them months either side of the date. The next GPS rollover is in November 2038, which puts two independent fixed-width overflows in the same year.
Why it still matters
Y2K is the only large-scale computing catastrophe that was seen coming decades out, taken seriously, funded, and worked through in advance — and its reward was to be remembered as a joke. Success in this line of work is indistinguishable from there never having been a problem.
Every engineer who has ever been asked why the budget went to something that then failed to happen is standing in the same place. The Y2K argument is unfalsifiable in both directions, and it is the argument you will have every time you ask for money to prevent something.
The other lesson is simpler and is being ignored right now. The two-digit year worked fine for thirty years and then cost $100 billion, because software outlives every assumption made while writing it. Windowing bought another twenty years by moving the same problem down the road. Somebody is currently making that trade again, on the reasonable grounds that they will not be there when it comes due.
Further reading
- US Department of Commerce — The Economics of Y2K and the Impact on the United States (November 1999). Where the $100 billion figure comes from, with its own error bars.
- Senate Special Committee on the Year 2000 Technology Problem — Y2K Aftermath: Crisis Averted. The official position, including its concessions.
- GAO/AIMD-00-290 — Year 2000 Computing Challenge: Lessons Learned. The documented federal failures.
- John Quiggin — The Y2K scare: causes, costs and cures. The best-argued case for the other side.
EXHIBIT 0004 — Y2K
We put it on a shirt. Not the apocalypse that was advertised — the actual bug, on the actual clock, for forty-five minutes.
Most people who see it will read it as nostalgia for a party. A smaller number will look at the number and know that it is not 19100 because someone got the year wrong, but because someone wrote "19" + 100.
That's the whole idea.