Year 2000 problem

The Year 2000 problem (also known as the Y2K problem, the millennium bug, the Y2K bug, or simply Y2K) was a notable computer bug resulting from the practice in early computer program design of representing the year with two digits. This caused some date-related processing to operate incorrectly for dates and times on and after January 1, 2000 and on other critical dates which were billed "event horizons". This fear was fueled by the attendant press coverage and other media speculation, as well as corporate and government reports. People recognized that long-working systems could break down when the "...97, 98, 99..." ascending numbering assumption suddenly became invalid. Companies and organizations world-wide checked and upgraded their computer systems.

While no significant computer failures occurred with global significance when the clocks rolled over into 2000, preparation for the Y2K bug had a significant effect on the computer industry. The fact that countries where very little was spent on tackling the Y2K bug (such as Italy and South Korea) fared just as well as those who spent much more (such as the United Kingdom and the United States) has generated debate on whether the absence of computer failures was the result of the preparation undertaken or whether the significance of the problem had been overstated.[1]

Contents

Background

Y2K was the common abbreviation for the year 2000 software problem. The abbreviation combines the letter Y for "year", and k for the Greek prefix kilo meaning 1000; hence, 2K signifies 2000. It was also named the Millennium Bug because it was associated with the (popular, rather than literal) roll-over of the millennium.

The Year 2000 problem was the subject of the early book, "Computers in Crisis" by Jerome and Marilyn Murray (Petrocelli, 1984; reissued by McGraw-Hill under the title "The Year 2000 Computing Crisis" in 1996). The first recorded mention of the Year 2000 Problem on a Usenet newsgroup occurred Saturday, January 19, 1985 by Usenet poster Spencer Bolles.[2]

The acronym Y2K has been attributed to David Eddy, a Massachusetts programmer,[3] in an e-mail sent on June 12, 1995. He later said, "People were calling it CDC (Century Date Change) and FADL (Faulty Date Logic). There were other contenders. It just came off my COBOL calloused fingertips."

It was speculated that computer programs could stop working or produce erroneous results because they stored years with only two digits and that the year 2000 would be represented by 00 and would be interpreted by software as the year 1900. This would cause date comparisons to produce incorrect results. It was also thought that embedded systems, making use of similar date logic, might fail and cause utilities and other crucial infrastructure to fail.

The Y2K problem is the electronic equivalent of the El Niño and there will be nasty surprises around the globe. – John Hamre, Deputy Secretary of Defense [4]

Special committees were set up by governments to monitor remedial work and contingency planning, particularly by crucial infrastructures such as telecommunications, utilities and the like, to ensure that the most critical services had fixed their own problems and were prepared for problems with others. It was only the safe passing of the main "event horizon" itself, January 1, 2000, that fully quelled public fears.

In North America the actions taken to remedy the possible problems had unexpected benefits. Many businesses installed computer backup systems for critical files. The Y2K preparations had an impact on August 14, 2003 during the Northeast Blackout of 2003. The previous activities had included the installation of new electrical generation equipment and systems, which allowed for a relatively rapid restoration of power in some areas.

Programming problem

The practice of using two-digit dates for convenience long predates computers, notably in artwork. Abbreviated dates do not pose a problem for humans, as works and events pertaining to one century are sufficiently different from those of other centuries. Computers, however, are unable to make such distinctions.

I’m one of the culprits who created this problem. I used to write those programs back in the 1960s and 1970s, and was proud of the fact that I was able to squeeze a few elements of space out of my program by not having to put a 19 before the year. Back then, it was very important. We used to spend a lot of time running through various mathematical exercises before we started to write our programs so that they could be very clearly delimited with respect to space and the use of capacity. It never entered our minds that those programs would have lasted for more than a few years. As a consequence, they are very poorly documented. If I were to go back and look at some of the programs I wrote 30 years ago, I would have one terribly difficult time working my way through step-by-step. Alan Greenspan[5]

In the 1960s, computer memory was scarce and expensive, and most data processing was done on punch cards which represented text data in 80-column records. Programming languages of the time, such as COBOL and RPG, processed numbers in their ASCII or EBCDIC representations. They occasionally used an extra bit called a "zone punch" to save one character for a minus sign on a negative number, or compressed two digits into one byte in a form called binary-coded decimal, but otherwise processed numbers as straight text. Over time the punch cards were converted to magnetic tape and then disk files and later to simple databases like ISAM, but the structure of the programs usually changed very little. Popular software like dBase continued the practice of storing dates as text well into the 1980s and 1990s.

Saving two characters for every date field was significant in the 1960s. Since programs at that time were mostly short-lived affairs programmed to solve a specific problem, or control a specific hardware setup, neither managers nor programmers of that time expected their programs to remain in use for many decades. The realization that databases were a new type of program with different characteristics had not yet come, and hence most did not consider fixing two digits of the year a significant problem. There were exceptions, of course; the first person known to publicly address the problem was Bob Bemer who had noticed it in 1958, as a result of work on genealogical software. He spent the next twenty years trying to make programmers, IBM, the US government and the ISO aware of the problem, with little result. This included the recommendation that the COBOL PICTURE clause should be used to specify four digit years for dates. This could have been done by programmers at any time from the initial release of the first COBOL compiler in 1961 onwards. However, lack of foresight, the desire to save storage space, and overall complacency prevented this advice from being followed. Despite magazine articles on the subject from 1970 onwards, the majority of programmers only started recognizing Y2K as a looming problem in the mid-1990s, but even then, inertia and complacency caused it to be mostly ignored until the last few years of the decade.

Storage of a combined date and time within a fixed binary field is often considered a solution, but the possibility for software to misinterpret dates remains, because such date and time representations must be relative to a defined origin. Rollover of such systems is still a problem but can happen at varying dates and can fail in various ways. For example:

Even before January 1, 2000 arrived, there were also some worries about September 9, 1999 (albeit lesser compared to those generated by Y2K). This date could also be written in the numeric format, 9/9/99. This date value was frequently used to specify an unknown date; it was thus possible that programs might act on the records containing unknown dates on that day.[7] It is also somewhat similar to the end-of-file code, 9999, in old programming languages. It was feared that some programs might unexpectedly terminate on that date. The bug, however, was more likely to confuse computer operators than machines.

Another related problem for calculations involving the year 2000 was that it was a leap year even though years ending in "00" are normally not leap years. A year is a leap year if it is divisible by 4 but not divisible by 100 unless also divisible by 400. For example, 1600 was a leap year, but 1700, 1800 and 1900 were not. Fortunately most programs were fixed in time, although the vast majority relied on the wrong, oversimplified rule that a year divisible by 4 is a leap year, which works on 2000.

The problem was compounded by the need of many systems, especially in the financial services sector, to calculate expiration and renewal dates in the future. For example, a company tracking five-year bonds would experience Y2K problems in 1995, when its systems needed to calculate an expiration date of 2000, which with two-digit years, its "00" expiration year would seem to be earlier than the "95" of the issue date.

Documented errors

Before 2000

On 1 January 2000

When January 1, 2000 arrived, there were problems generally regarded as minor. Problems did not always have to occur precisely at midnight. Some programs were not active at that moment and would only show up when they were invoked. Not all problems recorded were directly linked to Y2K programming in a causality; minor technological glitches occur on a regular basis.

Reported problems include:

Government responses

United States

The United States Government responded to the Y2K threat by passing the Year 2000 Information and Readiness Disclosure Act, by working with private sector counterparts in order to ensure readiness, and by creating internal continuity of operations plans in the event of problems. The effort was coordinated out of the White House by the President’s Council On Year 2000 Conversion, headed by John Koskinen.[13] The White House effort was conducted in coordination with the then-independent agency FEMA, as well as an interim Critical Infrastructure Protection Group, then in the Department of Justice, now in Homeland Security. The US Government promoted Y2K Information Sharing and Analysis Centers (ISACs) to share readiness between industries, without threat of antitrust violations or liability based on information shared.

The US Government followed a three part approach to the problem: (1) Outreach and Advocacy (2) Monitoring and Assessment and (3) Contingency Planning and Regulation.[14]

A feature of US Government outreach was Y2K websites including Y2K.GOV. Presently, many US Government agencies have taken down their Y2K websites. Some of these documents may be available through National Archives and Records Administration[15] or The Wayback Machine.

Each federal agency had its own Y2K task force which worked with its private sector counter parts. The FCC had the FCC Year 2000 Task Force.[16][17]

Most industries had contingency plans that relied upon the Internet for backup communications. However, as no federal agency had clear authority with regard to the Internet at this time (it had passed from the US Department of Defense to the US National Science Foundation and then to the US Department of Commerce), no agency was assessing the readiness of the Internet itself. Therefore on July 30, 1999 the White House held the White House Internet Y2K Roundtable.[18]

Norway and Finland

Norway and Finland changed their National identification number, to indicate the century in which a person was born. Previously the birth year was indicated with two digits only. Norway and Finland have a similar system. People born in the 20th century did not have to change their number. However, a similar problem already existed, the "Year 1900 problem", about distinguishing between people born in the 19th or 20th century, so the timing was more because of the Y2K attention than a solution to a new problem.

Private sector response

The Y2K issue was a major topic of discussion in the late 1990s and, predictably, showed up in most popular media. A number of "Y2K disaster" books were published such as Deadline Y2K by Mark Joseph. Movies such as Y2K: Year to Kill capitalized on the currency of Y2K, as did numerous TV shows, comic strips, and computer games.

Was the cost justified?

The total cost of the work done in preparation for Y2K is estimated at over 300 billion US dollars.[20] There are two ways to view the events of 2000 from the perspective of its aftermath:

Supporting view

This view holds that the vast majority of problems had been fixed correctly, and the money was well spent. The situation was essentially one of preemptive alarm. Those who hold this view claim that the lack of problems at the date change reflect the completeness of the project, and that many computer applications would not have continued to function into the 21st century without correction or remediation.

Opposing view

Others have claimed that there were no, or very few, critical problems to begin with, and that correcting the few minor mistakes as they occurred (the 'fix on failure' approach) would have been the most efficient and cost effective way to solve the problem. Editorial writing in the Wall Street Journal called Y2K an end-of-the-world cult and the hoax of the century.[26] The opposing view was bolstered by a number of observations.

Y2K in popular culture

See also

  • ISO 8601
  • Year 1900 problem
  • Year 2007 problem
  • Year 2038 problem
  • Year 2070 problem
  • Year 10,000 problem
  • Time formatting and storage bugs
  • Problems with epoch-based computer time representation

References

  1. Was Y2K bug a boost? from bbc.co.uk
  2. Google Groups - net.bugs - "Computer bugs in the year 2000." Retrieved on 22 April 2007.
  3. American RadioWorks Y2K Notebook Problems - The Surprising Legacy of Y2K. Retrieved on 22 April 2007.
  4. Looking at the Y2K bug, portal on CNN.com
  5. Testimony by Alan Greenspan, ex-Chairman of the Federal Reserve before Senate Banking Committee, February 25, 1998 ISBN 0-16-057997-X
  6. Microsoft Knowledge Base article 214326
  7. Merlyn - Critical and Significant Dates - J R Stockton
  8. Millennium bug hits retailers, from BBC News, 29 December 1999
  9. 9.0 9.1 Y2K bug fails to bite, from BBC News, 1 January 2000
  10. 10.0 10.1 Computer problems hit three nuclear plants in Japan, report by Martyn Williams of CNN, 3 January 2000
  11. 11.0 11.1 11.2 Minor bug problems arise, report from BBC News, 1 January 2000
  12. Preparation pays off; world reports only tiny Y2K glitches, report by Marsha Walton and Miles O'Brien of CNN, 1 January 2000
  13. White House shifts Y2K focus to states, CNN (Feb. 23, 1999)
  14. FCC Y2K Communications Sector Report (March 1999) copy available at WUTCPDF (1.66 MiB)
  15. See President Clinton: Addressing the Y2K Problem, White House, Oct. 19, 1998
  16. FCC Y2K Communications Sector Report (March 1999) copy available at WUTCPDF (1.66 MiB)
  17. Federal Communications Commission Spearheads Oversight of the U.S. Communications Industries' Y2K Preparedness, Wiley, Rein & Fielding Fall 1999
  18. Basic Internet Structures Expected to be Y2K Ready, Telecom News, NCS (1999 Issue 2)PDF (799 KiB)
  19. Internet Year 2000 Campaigned archived at Cybertelecom
  20. Y2K: Overhyped and oversold?, report from BBC, 6 January 2000
  21. Department of State Washington File: Transcript: What Happened to Y2K? Koskinen Speaks Out
  22. Y2K readiness helped New York after 9/11, article by Lois Slavin of MIT News, 20 November 2000
  23. September 11 and the U.S. Payment System, article by Christine M. Cumming of the International Monetary Fund
  24. Y2K readiness helped NYC on 9/11, article by Rae Zimmerman of MIT News, 19 November 2000
  25. Plan for the Security Control of Air Traffic and Air Navigation Aids (Short Title: SCATANA), April 1980
  26. Taranto, James (2003-02-03). "The Year 2003 Problem". .
  27. White House: Schools lag in Y2K readiness: President's Council sounds alarm over K-12 districts' preparations so far, article by Jonathan Levine of eSchool News, 01 September 1999
  28. Most small businesses win their Y2K gamble, article by Kent Hoover, 10 January 2000
  29. Y2K travel warning issued, report by Fiona Reynolds of ABC Radio, 1 December 1999
  30. Fight or Flight?: Assessing Your Y2K Travel Risks, article by Tracy Davis of Boston College, 1999
  31. Lights out? Y2K appears safe, article by Elizabeth Weise of USA Today, 14 February 1999
  32. Y2K bug may never bite, article by John Quiggin of the Australian Financial Review, 02 September 1999

External links