About Opentopia
Opentopia Directory Encyclopedia Tools

Year 2000 problem

Encyclopedia : Y : YE : YEA : Year 2000 problem

"Y2K" redirects here. For , 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 computer program design that caused some date-related processing to operate incorrectly for dates and times on and after January 1, 2000. It turned into a major fear that critical industries (such as electricity or financial) and government functions would stop working at exactly midnight, January 1, 2000, and at other critical dates which were billed as "event horizons". This fear was fueled by the press coverage and other media speculation, as well as corporate and government reports. All over the world companies and organizations checked and upgraded their computer systems. The preparation for Y2K had a significant effect on the computer industry.

Contents

Background

Y2K (properly Y2k) was the common abbreviation for the year 2000 problem. The abbreviation combines the letter Y for "year", and k for the Greek suffix kilo meaning 1000; hence, 2k means 2000. It also went by millennium bug because it was mistakenly associated with a roll-over of the millennium.

The term was coined on June 12, 1995 in an e-mail sent by David Eddy, a Massachusetts programmer. 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 vast segments of the economy; however, most of the offices had purchased backup servers in New Jersey and elsewhere, limiting the devastation 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, as can easily be demonstrated by visiting an art museum. Saving scarce memory was only an issue for a very short part of the computer age, but since that age happened to fall near the middle of a century users and programmers became lazy. The fundamental issue is that humans can use context to disambiguate: we look at an Impressionist painting signed "Monet '73" or an abstract painting signed "Picasso '39" and we know one was done in the nineteenth century while the other in the twentieth; computers don't recognize context.

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 care about 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. [link] 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 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.) Fortunately most programs were fixed in time.

Public reaction to the problem

As the decade progressed, identifying and correcting or replacing affected computer systems or computerized devices became the major focus of information technology departments in most large companies and organizations. Millions of lines of programming code were reviewed and fixed during this period. Many corporations replaced major software systems with completely new ones that did not have the date processing problems. It was reported that corporations had already experienced minor Y2K problems due to date look-ahead functions in code and embedded systems, but it was and still is not clear what the full cost and seriousness of these problems were.

In some countries public apprehension was growing. Some individuals stockpiled canned or dried food in anticipation of food shortages. A few commentators predicted a full-scale apocalypse, among them computer consultant Edward Yourdon, televangelist Jack Van Impe, religious commentator Gary North, and economist Edward Yardeni. In discussion groups devoted to the issue, this position was referred to by the acronym TEOTWAWKI for 'the end of the world as we know it', and those who held it were called doomsayers.

Another group of commentators argued that few or no problems would emerge, and that the appropriate policy response was not large-scale attempts to make systems Y2K-compliant, but a "fix on failure" response for all but the most critical systems. These commentators were often labelled Pollyannas.

The dominant view, which determined policy in the United States and other English-speaking countries, and to a lesser extent in the rest of the world was that the problem was sufficiently serious to justify a large-scale response, but that such a response should be sufficient to resolve the problem.

Documented errors

Before the year 2000

Midnight

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. [link] There are two ways to view the events of 2000 from the perspective of its aftermath:

Supporting view

The vast majority of problems had been fixed correctly, and the money was well spent. The lack of problems at the date change reflect the completeness of the project. This view was adopted by most of the (fairly limited) official examinations of Y2K projects undertaken after their completion. It has been suggested that on September 11, 2001 the New York financial infrastructure was able to continue operation because of the redundent networks established in event of the Y2K bug. The terrorist attacks and the following prolonged blackout to lower Manhattan had minimal effect on global banking systems. 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 finacial district on December 31, 1999. Had the emphasis on creating backup systems to deal with Y2K not occurred, much greater disruption to the economy could have occurred. Decentralization of infrastructure--in particular, the creation of multiple sites for backup data--helped keep banks up and running.

Opposing view

There were no critical problems to begin with, and correcting the few minor mistakes as they occurred would have been the most efficient and cost effective way to solve the problem. This view was bolstered by a number of observations.

Facts, Figures and Folklore

Facts

Rumors

''These are unreferenced anecdotes and urban legends.

Quotes

Y2K in popular culture

See also

References

External links

 

From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.

Search Titles
0123456789
ABCDEFGHIJ
KLMNOPQRST
UVWXYZ?

E-mail this article to:

Personal Message: