Arikah Map

Year 2000 problem

(Redirected from Y2K bug)

"Y2K" redirects here. For the year 2000 in general, see 2000.

The Year 2000 problem (also known as the Y2K problem, the millennium bug, and the Y2K Bug) was the result of a practice in early computer program design that caused some date-related processing to operate incorrectly for dates and times on and after January 1, 2000. It engendered widespread concern that critical industries (such as electricity or financial) and government functions would cease operating at exactly midnight, January 1, 2000, and on other critical dates which were billed as "event horizons". This fear was fueled by the attendant press coverage and other media speculation, as well as corporate and government reports. Companies and organizations world-wide checked and upgraded their computer systems. The preparation for Y2K thus had a significant effect on the computer industry. No significant computer failures occurred when the clocks rolled over into 2000. Debate continues on whether the absence of computer failures was the result of the preparation undertaken or whether the significance of the problem had been overstated.


Contents

Background

Y2K was the common abbreviation for the Year 2000 Problem. The abbreviation combines the letter Y for "year", and k for the Greek prefix kilo meaning 1000; hence, 2K signifies 2000. It also named the Millennium Bug because it was associated with a roll-over of the millennium.

The first recorded mention of the Year 2000 Problem was on a Usenet Newsgroup on Saturday, January 19, 1985 by Usenet poster, Spencer Bolles.[1].

The term was coined on June 12, 1995 in an e-mail sent by David Eddy, a Massachusetts programmer [2]. 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.

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 did have unexpected benefits. Many businesses installed computer backup systems for critical files. The September 11 attacks destroyed hundreds of offices in the World Trade Center, potentially crippling segments of the economy; however, most of the offices had purchased backup servers in New Jersey and elsewhere, limiting the economic impact of the attacks. The Y2K preparations further had impact on August 14, 2003 during the 2003 North America blackout. 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.

The programming problem

The underlying programming problem was real, but more subtle than many realize.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.

In the 1960s, computer memory and storage were 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. Roll-over 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. [3] 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 rather 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.

The problem was compounded by the need of many systems, especially in the financial services sector, to calculate expiry and renewal dates in the future. For example, a company that sold five-year bonds would start getting Y2K problems in 1995, when its systems needed to calculate an expiry date of 2000; with two-digit years, the "00" of the expiry date would appear to be earlier than the "95" of the start 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 causal relationship; minor technology glitches occur on a regular basis, as anyone who ever had to reboot a personal computer will recognize.

Reported problems include:

Was the expenditure worth the effort?

The total cost of the work done in preparation for Y2K was $US 300 billion. [12] 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. 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.

This view was adopted by most of the (fairly limited) official examinations of Y2K projects undertaken after their completion[13].

It has also been suggested that on September 11, 2001, the New York infrastructure (including subways, phone service, and financial transactions) were able to continue operation because of the redundant networks established in the event of Y2K bug impact[14] and the contingency plans devised by companies[15]. The terrorist attacks and the following prolonged blackout to lower Manhattan had minimal effect on global banking systems[citation needed]. Backup systems were activated at various locations around the region, many of which had been established to deal with a possible complete failure of networks in the financial district on December 31, 1999 [16]. Had the emphasis on creating backup systems to deal with Y2K not occurred, much greater disruption to the economy could have occurred[citation needed]. Decentralization of infrastructure—in particular, the creation of multiple sites for backup data—helped keep banks up and running [citation needed].

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. This view was bolstered by a number of observations.

Facts

Rumors

These are unreferenced anecdotes and urban legends.

Quotes

See also

References

Categories


Articles with unsourced statements | Calendars | COBOL | Numbers in pop culture | Internet culture | Mass hysteria | Problems | System software | 2000

Find

Find

Find