Y2K

The Year 2000 problem (also known as the Y2K problem, the millennium bug, the Y2K Bug or just Y2K) 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 caused widespread concern that critical industries (such as electricity or finance) 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. People recognized that finely tuned systems could get "confused" when the 97, 98, 99, ?? ascending numbering assumption suddenly became invalid. 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 [hide] 1 Background 2 The programming problem 3 Documented errors 3.1 Before 2000 3.2 On 1 January 2000 4 Government Response 4.1 US Government 5 Was the expenditure worth the effort? 5.1 Supporting view 5.2 Opposing view 6 Facts, figures and popular culture 6.1 Facts 6.2 Quotes 6.3 Y2K in popular culture 7 See also 8 References 9 External links

[edit] 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 a 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.[1]

The acronym Y2K has been attributed to David Eddy, a Massachusetts programmer,[2] 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."[citation needed]

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.

However, the Y2K problem chiefly affects programs that operate in decimal arithmetic. Most computers and computer languages support only binary arithmetic. Decimal arithmetic was a feature of early IBM mainframe computers and was supported in a few early languages: COBOL, FORTRAN, and PL/I. However, most computers in use now are personal computers, and most of them run operating systems and applications written in C. For these computers, decimal arithmetic is an anachronism. The only way a Y2K problem can occur is when a year is converted from a binary integer to a string for disk storage or output to a screen or printer.

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.

[edit] 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 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:

The typical Unix timestamp (time_t) stores a date and time as a 32-bit signed integer number representing, roughly speaking, the number of seconds since January 1, 1970, and will roll over in 2038 and cause the Year 2038 problem. To solve this problem, many systems and languages have switched to a 64-bit version, or supplied alternatives which are 64-bit. The popular spreadsheet Microsoft Excel stores a date as a number of days since an origin (often erroneously called a Julian date). A "Julian date" stored in a 16-bit integer will overflow after 65,536 days (approximately 179 years). Unfortunately, the Windows versions of the program by default start at 1900 and the Mac versions by default start at 1904 (although this can usually be changed). The Microsoft Excel spreadsheet program also had a very elementary Y2K problem: Excel (in both Windows versions and Mac version, when they are set to start at 1900) incorrectly set the year 1900 as a leap year. In addition, the years 2100, 2200 and so on were regarded as leap years. This bug was fixed in later versions, but since the epoch of the Excel timestamp was set as January 1, 1900 in previous versions, the year 1900 is still regarded as a leap year to maintain backward compatibility. In the C programming language, the standard library function to get the current year originally did have the problem that it returned only the year number within the 20th century, and for compatibility's sake still returns the year as year minus 1900. Many programmers in C, and in Perl and Java, two programming languages widely used in Web development that use the C functions, incorrectly treated this value as the last two digits of the year. On the Web this was a mostly harmless bug, but it did cause many dynamically generated webpages to display January 1, 2000, as "1/1/19100", "1/1/100", or variations of that depending on the format. Older applications written for the commonly used UNIX source code control system SCCS failed to handle years that began with the digit "2". In the Windows 3.1 file manager, dates were shown as 1/1/19:0 for 1/1/2000. An update was available on the internet, and this operating system was not used so much any more anyway. 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. [1] 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 simply rely on the rule that a year divisible by 4 is always a leap year, which incidentally works well on 2000; if the change of century had been 1899-1900 or 2099-2100 (non leap century years), then virtually every piece of software would have had to be changed.

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 that sold five-year bonds would start getting Y2K problems in 1995, when its systems needed to calculate an expiration date of 2000; with two-digit years, the "00" of the expiration date would appear to be earlier than the "95" of the start date.