Encyclopedia of Computer Science and Technology

YY2K problemSherlock Holmes once referred to a dog barking in thenight. Watson, puzzled as usual, replied that no dog hadbarked. Holmes replied that it was the nonbarking that wassignificant. The same can be said about the growing concerntoward the end of the 1990s that the year 2000 mightbring massive, disastrous failures to many of the computersystems on which society now depended for its well-being.Most programs written in the 1960s and 1970s (seemainframe and cobol) saved expensive memory space bystoring only the second two digits of year dates. After all,dates could be understood to begin with “19” for manyyears to come (although some farsighted computer scientistsdid warn of future trouble). Eventually the centurybegan to draw to an end.Although much computing activity had moved ontonewer systems by the 1990s, many large government andcorporate computer systems were still running the originalapplications or their descendents. If such a program wererun in the year 2000, it would have no way to distinguisha date in that year from a date in 1900. While the prospectof a centenarian being suddenly treated as a newborn waslikely to be more amusing than significant, what wouldhappen to a 30-year mortgage that was written in 1975and intended to come due in 2005? Would people be billedbased on a 70-year term? Many observers feared that somesystems would actually crash because they would begin togenerate nonsensical data. What, for example, might happento an air traffic control system or automated power gridsystem that used dates and times to track events?No one really knew. One problem was that there weremillions of lines of code, often written by programmerswho had long since retired. Nor was it simply a matter oflooking for references to date fields (such as in decisionstatements), because of the many ways programmers couldexpress such statements. In addition to mainframe applications,there were also the computers hardwired into devicesof all kinds including cars and airplanes (see embeddedsystem). As with the early mainframes, these systems wereoften designed with limited available memory, and thustheir programmers, too, may have been tempted to savebytes by lopping off the century years.As the fateful date approached, government agenciesand businesses began to invest billions of dollars and hireexpensive consultants to check code for “Y2K compatibility.”In the end, Y2K problems were found and fixedin the most critical systems, and the year 2000 dawnedwithout significant mishaps. (It turned out that virtually allthe embedded systems did not in fact have Y2K problems,mostly because they didn’t even track year dates.)But although the “dog didn’t bark” and in retrospectsome of the hype about Y2K seems excessive, it did leadto improvement in a great deal of software. Further, itincreased awareness of dependence on computers for somany aspects of life—a dependence that has been cast ina harsh new light by the terrorist events of September 11,2001 (see risks of computing).Further ReadingCrawford, Walt. “Y2K: Lessons from a Non-Event.” Online, vol. 25,issue 2, March 2001, 73.522