The Y2K Problem
Year 2000 problem, also known as the Y2K problem, the Millennium bug, Y2K bug, the Y2K glitch, or Y2K, refers to events related to the formatting and storage of calendar data for dates beginning in the year 2000. Problems were anticipated, and arose, because many programs represented four-digit years with only the final two digits – making the year 2000 indistinguishable from 1900. The assumption of a twentieth-century date in such programs could cause various errors, such as the incorrect display of dates and the inaccurate ordering of automated dated records or real-time events.
As the turn of the millennium approached no one was sure what would happen, with wild stories of planes dropping out of the sky, nuclear weapons firing on their own, and other unknown issues, hardware and software was created and sold as”Y2k Fixes”. On January 1, 2000 nothing happened except the buyers of these “fixes” felt like they had been “had”.
In 1997, the (BSI) developed standard, DISC PD2000-1 defining “Year 2000 Conformity requirements” as four rules:
- No valid date will cause any interruption in operations.
- Date-based functionality must behave consistently for dates prior to, during and after year 2000.
- In all interfaces and in all storage, the century must be unambiguous, either specified, or calculable by algorithm.
- Year 2000 must be recognised as a leap year.
It identifies two problems that could have existed in many computer programs. First, the practice of representing the year with two digits became problematic with logical error(s) arising upon “rollover” from xx99 to xx00. This had caused some date-related processing to operate incorrectly for dates and times on and after 1 January 2000, and on other critical dates which were billed “event horizons”. Without corrective action, long-working systems would break down when the “… 97, 98, 99, 00 …” ascending numbering assumption suddenly became invalid.
Secondly, some programmers had misunderstood the Gregorian calendar rule that states years that are exactly divisible by 100 are not leap years, assuming that the year 2000 would not be a leap year. In reality, there is a rule in the Gregorian calendar system that states years divisible by 400 are leap years – thus making 2000 a leap year.
Correcting all of this, however, was not the largest part of the problem. By 1997, AT&T had estimated that “60% of the time and money needed for its total compliance efforts” would be devoted to testing the source code changes made to address the issue.
Companies and organizations in some countries, but not all, checked, fixed, and upgraded their computer systems to address the anticipated problem. Very few computer failures were reported when the clocks rolled over into 2000.