Year 2000 problem

The Year 2000 problem (also known as the Y2K problem, the millennium bug, the Y2K Bug, or simply 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 the stroke of midnight between December 311999 and 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 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 (like Italy and Korea) fared just as well as those who spent a lot (like the UK and the US) 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.

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.

The acronym Y2K has been attributed to David Eddy, a Massachusetts programmer, 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

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.

The 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

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 (exceed 32 bits) 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 Microsoft Excel spreadsheet program 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 to the meaningless date of January 0 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 represents 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 usually was a 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.

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. 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 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

• In 1999 HSBC issued 10,000 card swipe machines, manufactured by Racal, to retailers, but a Y2K flaw prevented them from reading expiration dates properly. The stores had to rely on paper transactions, as they do when there are power failures or phone line failures, until replacement machines arrived.

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:

• In the Philippines, BPI (Bank of the Philippine Islands) Auto Teller Machines read the error SYS. 34 00 at 00:00. The problem was fixed the next morning at 6:45.
• In Ishikawa, Japan, radiation-monitoring equipment failed at midnight, but officials said there was no risk to the public.
• In Onagawa, Japan, an alarm sounded at a nuclear power plant at two minutes after midnight.
• In Japan, at two minutes past midnight, Osaka Media Port, a telecommunications carrier, found errors in the date management part of the company's network. The problem was fixed by 2:43 a.m. and no services were disrupted.
• In Japan, NTT Mobile Communications Network (NTT DoCoMo), Japan's largest cellular operator, reported on January 1, 2000, that some models of mobile telephones were deleting new messages received, rather than the older messages, as the memory filled up.
• In Australia, bus-ticket-validation machines in two states failed to operate.
• In the United States, 150 slot machines at race tracks in Delaware stopped working.
• In the United States, the U.S. Naval Observatory, which runs the master clock that keeps the country's official time, had a Y2K glitch on its Web site. Due to a programming problem, the site reported that the date was Jan. 1, "19100."
• In the United States, fare collection turnstiles at PATH stations throughout New York City & New Jersey failed to operate.
• In France, the national weather forecasting service, Meteo France, said a Y2K bug made the date on a webpage show a map with Saturday's weather forecast as "01/01/19100".

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 headed out of the White House by the President’s Council On Year 2000 Conversion, headed John Koskinen. The White House effort was conducted in coordination with the then-independent agency FEMA, which was well staffed and thoroughly prepared in the event it was needed. 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.

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 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.

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.

Private sector response

• The United States established the Year 2000 Information and Readiness Disclosure Act, which limited the liability of businesses who had properly disclosed their Y2K readiness.
• Insurance companies sold insurance policies covering failure of businesses due to Y2K problems.
• Attorneys organized and mobilized for Y2K class action lawsuits (which were not pursued).
• Survivalist-related businesses (gun dealers, surplus and sporting goods, LDS bookstores selling freeze-dried food) anticipated increased business in the final months of 1999. Some of these businesses experienced increased sales; some did not.
• The Long Now Foundation, which (in their words) "seeks to promote 'slower/better' thinking and to foster creativity in the framework of the next 10,000 years", has a policy of anticipating the Year 10,000 problem by writing all years with five digits. For example, they list "01996" as their year of founding.
• While there was no one comprehensive Internet Y2K effort, multiple Internet trade associations and organizations banded together to form the Internet Year 2000 Campaign. This effort partnered with the White House's Internet Y2K Roundtable.

The Y2K issue was a major topic of discussion in the late 1990's 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. 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.

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

• 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 and the contingency plans devised by companies. 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 financial 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.

• It was suggested that Y2K plans were used to ground aircraft on 9/11, but the grounding was a variant of the SCATANA procedures developed in the 1970s.

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.

• The lack of Y2K-related problems in schools, many of which undertook little or no remediation effort. By September 1, 1999 only 28 percent of US schools had achieved compliance for mission critical systems, and a government report predicted that "Y2K failures could very well plague the computers used by schools to manage payrolls, student records, online curricula, and building safety systems".

• The lack of Y2K-related problems in an estimated 1.5 million small businesses that undertook no remediation effort. On 3 January 2000 (the first weekday of the year) the Small Business Administration received an estimated 40 calls from businesses with computer problems, similar to the average. None of the problems were critical.

• The lack of Y2K-related problems in countries such as Italy, which undertook a far more limited remediation effort than the United States. In an October 22, 1999, report, a US Senate Committee expressed concern about safe travel outside of the United States. The report stated that overseas public transit systems were considered vulnerable because many did not have an aggressive response plan in place for any problems. Internationally, the report singled out Italy, China and Russia as poorly prepared. The Australian government evacuated all but three embassy staff from Russia. None of these countries experienced any Y2K problems regarded as worth reporting.

• The absence of Y2K-related problems occurring before January 1, 2000, even though the 2000 financial year commenced in 1999 in many jurisdictions, and a wide range of forward-looking calculations involved dates in 2000 and later years. Estimates undertaken in the leadup to 2000 suggested that around 25% of all problems should have occurred before 2000. Critics of large-scale remediation argued, during 1999, that the absence of significant problems, even in systems that had not been rendered compliant, suggested that the scale of the problem had been overestimated.

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

Y2K in popular culture

• The episode Da Boom of the hit TV series Family Guy, Peter Griffin frightens over Y2K. In the end he turns out to be right and starts New Quahog.
• WWE superstar Chris Jericho's nickname is Y2J. When he debuted in the WWE in 1999 he used the turn of the millennium as a gimmick so his nickname is probably a parody to Y2K.
• A Simpsons Halloween special, Treehouse of Horror X, parodies the millennium bug. Due to Homer Simpson's incompetence of fixing the Y2K bug, everything that is electronical goes haywire, thus destroying the world.

External links

• BBC: Y2K coverage
• Y2K Compliance Checker by RJL Software
• The Surprising Legacy Of Y2K – Radio documentary by American Public Media, on the history and legacy of the millennium bug five years on.
• The Yawn of a New Millennium
• CBC Digital Archives - The Eve of the Millennium