Year 2000 Problem
In brief: For decades, many computers stored years as two digits, so "1999" was saved as "99". When the calendar reached 2000, "00" could be read as 1900, and date sums, sorting and age calculations could go wrong. Governments and companies spent hundreds of billions of dollars between about 1995 and 1999 finding and fixing the affected code, and the rollover passed with only minor, mostly local failures. The Y2K effort is the closest historical precedent for the Year 2038 problem.
| Risk level | n/a (historical) |
| Status | Resolved in 2000. Some "windowed" fixes from 1999 have since expired (see Related-Date-Bugs) |
| Last reviewed | 2026-10-21 |
Overview
The Year 2000 problem (Y2K, or the "millennium bug") was a class of software and firmware defects caused by recording the year with only its last two digits. A program that stores 99 for 1999 and 00 for 2000 will, unless told otherwise, conclude that 2000 comes before 1999, that someone born in 1950 is −50 years old in 2000, or that an invoice dated 00 is a century overdue.
The U.S. Senate Special Committee on the Year 2000 Technology Problem, which studied the issue from April 1998 until it disbanded on 29 February 2000, called Y2K preparation "one of the most complex and vast management challenges in recent history" and noted that "from roughly 1995-1999, private and public organizations, both domestically and internationally, mobilized huge resources to address Y2K" [1]. The committee judged that "the level of effort was justified, and the expenditures of the public and private sectors were indeed necessary" [1].
Why two digits?
- Memory and storage were expensive. Random-access memory in 1960 cost "roughly one million times as much, per unit of storage" as it did in 1999, wrote James Fallows. He also reported one economist's argument that two-digit years were still a rational choice in the 1950s because of the compounded value of those early savings [2].
- Punched cards and fixed-width records. Business data was laid out in fixed columns, and every column saved on a date field was saved in every record of every file.
- Industry standards locked it in. Time reported that IBM's System/360, the industry-standard machine of the 1960s, shipped with two-digit dates. The International Standards Organization adopted a four-digit date standard in the 1970s but "could not change the course IBM had set", and the Pentagon promised around 1974 to adopt century-friendly dates but did not follow through [3].
- Nobody expected the code to last. The programs written in the 1960s and 1970s, many in COBOL, were still running in the 1990s. Time estimated about 1.2 trillion lines of code needed checking [3].
Early warnings
Bob Bemer, a COBOL pioneer known as "the father of ASCII", is credited with the first public identification of the problem. In 1971 he published "What's the Date?" in the Honeywell Computer Journal, and in 1979 he wrote "Time and the Computer" for Interface Age [4]. He had invented COBOL's picture clause, which allowed a four-digit year, but Time says his warnings were met with derision and he retired in 1982 [3]. Peter de Jager's three-page Computerworld article "Doomsday 2000" (6 September 1993) is widely seen as the moment the issue reached mainstream IT management [5][6]. See Y2K-Timeline.
Technical details
Failure modes
| Failure mode | Example | What goes wrong |
|---|---|---|
| Comparison / sorting | IF EXPIRY-YY < CURRENT-YY |
00 < 99, so a 2000 expiry looks older than 1999 |
| Interval arithmetic | age = 00 − 50 |
Negative ages and durations. The Sheffield screening error (see Y2K-Incidents) was of this type [7] |
| Display with a hard-coded "19" | "19" + year where year = years since 1900 |
Prints 19100 for 2000. The U.S. Naval Observatory website showed "Jan. 1, 19100" for 45 minutes [8] |
| Parsing two-digit input | 00 assumed to be 1900 |
Records, licences and bills dated 1900 [1] |
| Sentinel values | 99 or 00 used to mean "never expires" or "end of file" |
Real dates collide with magic values |
| Leap-year logic | Century years treated as non-leap | 29 February 2000 rejected (see below) |
The "19100" bug is worth noting because it comes from APIs that return years since 1900, not from two-digit storage. C's struct tm.tm_year, Perl's localtime() and JavaScript's legacy getYear() all behave this way. The Naval Observatory error came from "an outdated JavaScript that wasn't Y2K-ready" running on a third-party host [8].
/* Classic 19100 bug: tm_year is years since 1900 (100 in the year 2000) */
printf("19%d\n", t->tm_year); /* prints 19100 */
printf("%d\n", 1900 + t->tm_year); /* correct: 2000 */
The leap year 2000
Gregorian calendar rules say a year divisible by 4 is a leap year, except a year divisible by 100, which is a leap year only if it is also divisible by 400. So 1900 and 2100 are not leap years, but 2000 is [9]. Software that applied only the first two parts of the rule treated 2000 as a common year and skipped 29 February. Organisations were "actively preparing for February 29, 2000", according to the Senate committee [1]. On the day, Computerworld reported only scattered failures: a hotel key-card system in Boston, Japan Meteorological Agency weather stations that reported erroneous readings, and about 5% of Japan Post's 25,000 ATMs printing receipts dated 1 March [10].
Software that uses only the simple "divisible by 4" rule happened to get 2000 right but will get 2100 wrong. Excel's deliberate treatment of 1900 as a leap year is a separate, documented compatibility bug [11]. See Related-Date-Bugs.
Fix strategies
The two main fixes were date expansion (store four-digit years) and windowing (keep two digits and infer the century using a pivot year). Encapsulation and replacement were also used. They are compared in detail in Y2K-Remediation-and-Cost. Windowing was cheaper and far more common. New Scientist estimated that about 80% of systems fixed in 1999 used it, which is why some windowed systems failed in January 2020 [12].
Affected versions / products
Y2K was not tied to one product. The Senate committee's incident appendix lists problems in utilities, healthcare, telecoms, transport, finance, government and embedded systems across the U.S. and 74 other countries [1][13].
| Area | Typical exposure (1990s) |
|---|---|
| Mainframe business systems (COBOL, PL/I, RPG) | Two-digit YY fields in records, copybooks and screens |
| PC BIOS / RTC chips | Real-time clocks that stored only two BCD year digits |
| Desktop apps and spreadsheets | Two-digit entry, pivot rules, the 1900 leap-year quirk |
| Embedded controllers | Date-stamped logs, maintenance timers, medical devices |
| Web scripts | getYear() / tm_year "19100" displays |
Outcome
The rollover produced no major failures. The Senate committee reported that "no major problems were experienced in the U.S. or worldwide during the millennium date change" [1]. Its examples of domestic problems included "Medicare payment delays, double-billing by some credit card companies, degradation of a spy satellite system, 911 problems in several localities, and a nuclear weapons plant system anomaly" [1]. Testing in late 1999 suggested an embedded-chip failure rate of about 0.001%, rather than the 2–3% projected in late 1998 and early 1999 [1]. GAO testified in January 2000 that "almost all Year 2000 failures were mitigated" through corrections or contingency actions [14]. Documented failures are collected in Y2K-Incidents.
The committee also gave reasons why international disruption was lower than predicted. Information about other countries' preparedness had been poor. Late starters benefited from U.S.-developed tools. Multinational corporations pushed suppliers to fix their systems. And many countries "simply rolled back computer clocks", which it called a temporary fix [1].
Because so little went wrong, many people later concluded the threat had been exaggerated. This is the "preparedness paradox", discussed in Y2K-Lessons-for-2038.
Risk & compliance notes
- Historical, but not finished. The Senate committee warned that windowed software "may encounter problems with the approach of the 'pivot year'", and that systems exchanging two-digit years with different pivots could disagree [1]. That prediction came true in 2020 [12].
- Governance precedent. Y2K created most of the governance tools that a 2038 programme would reuse: executive ownership, inventories, supplier certification, legal safe harbours, and command centres. See Y2K-Lessons-for-2038.
Detection & mitigation
For 2038 work, the Y2K techniques that still apply are inventory first, clock-forward testing in isolated environments, and checking interfaces as well as individual systems. See Testing-and-Detection and Remediation-Guide.
See also
- Y2K-Timeline
- Y2K-Remediation-and-Cost
- Y2K-Incidents
- Y2K-Lessons-for-2038
- Related-Date-Bugs
- Year-2038-Problem
- Glossary
References
- Y2K Aftermath – Crisis Averted: Final Committee Report (S. Prt. 106-42) — U.S. Senate Special Committee on the Year 2000 Technology Problem, 29 Feb 2000. Outcome, costs, embedded failure rate, pivot-year warning, and the incident appendix.
- Hurry Up Please It's Time — James Fallows, The New York Review of Books, 23 Sep 1999. The 1960 memory-cost comparison and the "rational choice" argument.
- The History and the Hype — Chris Taylor, Time, 18 Jan 1999. IBM System/360, ISO, the Pentagon's 1974 promise, Bemer's retirement, and 1.2 trillion lines of code.
- Guide to the Robert W. Bemer Papers — Computer History Museum (OAC finding aid). Bemer's 1971 "What's the Date?" and 1979 "Time and the Computer".
- Have we learned nothing from Y2K? — Computerworld, 1 Jan 2000. De Jager's warning in Computerworld on 6 Sep 1993.
- Y2K: The strange, true history of how Canada prepared… — The Globe and Mail, 28 Dec 2019. "Doomsday 2000" was a three-page Computerworld spread.
- Y2K Bug Blamed For Miscalculated Down Syndrome Risk — Slashdot, 13 Sep 2001 (relaying BBC News). Sheffield screening error.
- Y2K glitch a 'black eye' for Naval Observatory — Computerworld, 1 Jan 2000. The "19100" display.
- Method to determine whether a year is a leap year — Microsoft Learn. The Gregorian 4/100/400 rule.
- Leap day skips past with few problems — James Cope, Computerworld, 1 Mar 2000. Failures on 29 Feb 2000.
- Excel incorrectly assumes that the year 1900 is a leap year — Microsoft Learn. The Lotus 1-2-3 compatibility bug.
- This Year's Y2K20 Bug Came Directly From 'A Lazy Fix' to the Y2K Bug — Slashdot, 12 Jan 2020, summarising New Scientist. Windowing used for about 80% of 1999 fixes. Original: New Scientist.
- Senate: Y2K fixes worth the billions spent — DeWayne Lehman, Computerworld, 6 Mar 2000. The 13-page incident list covering the U.S. and 74 other countries.
- Year 2000 Computing Challenge: Leadership and Partnerships Result in Limited Rollover Disruptions (T-AIMD-00-70) — GAO, 27 Jan 2000. GAO's post-rollover testimony.