Year 2000 problem(redirected from Y2k scare)
Year 2000 problem,
millennium bug,in computer science, a design flaw in the hardware or software of a computer that caused erroneous results when working with dates beyond Dec. 31, 1999. In the 1960s and 70s programmers who designed computer systems dropped the first two digits of a year when storing or processing dates to save what then was expensive and limited memory; such a system recorded the year 2000 as 00 and could not distinguish it from 1900. In sorting, comparison, and arithmetic operations, the year 2000 would be treated as if it were equivalent to 0 rather than 100, causing incorrect results. The algorithm used to calculate leap years was also in some cases invalid, creating an additional problem in calculating the correct date after Feb. 28, 2000. Because the designers of such computer systems expected them to be replaced before the beginning of the year 2000, using a two-digit date was not regarded as a problem. Thousands of older computer systems, called legacy systems, were still in use in the 1990s, however, particularly in the finance and insurance industries, creating a potential operational and financial nightmare, which was termed Doomsday 2000Doomsday 2000,
term coined by Canadian computer consultant Peter de Jager in 1993 to describe the operational and financial impact of a defect of contemporary computer hardware and software, known as the Year 2000 problem, that caused computer programs to incorrectly perform
..... Click the link for more information. . In the late 1990s business, government, and other computer users spent thousands of hours and millions of dollars to correct the Year 2000 problem, and only minor problems were experienced after Jan. 1, 2000.
The Columbia Electronic Encyclopedia™ Copyright © 2013, Columbia University Press. Licensed from Columbia University Press. All rights reserved. www.cc.columbia.edu/cu/cup/
Y2K problem(Year 2000 problem) The inability of older hardware and software to recognize the date after the year 2000. The reason they could not was because the year was stored with only two digits in many databases; for example, 12-11-03 instead of 12-11-1903. Therefore, after the turn of the century, was this date 1903 or 2003? Every program that dealt with dates could have problems.
Dates Are Critical
Financial transactions often match dates in database records with today's date or with a future date. If the system does not handle dates correctly, bills do not get paid, notices do not get triggered and actions are not taken. After 2000, any system that could not recognize the change would cause erroneous output with applications that dealt with future dates. Although warnings of disaster prevailed, there were only a few incidents when all was said and done.
Fixing It Was a Massive Job
The solution to this "millennium bug" required upgrading hardware to support four-digit years, converting files and databases to four-digit years and converting all the software that referenced dates. Enterprises had a huge amount of legacy data files and thousands of programs that accessed them. With many older applications, the programmers who wrote them were long gone, and documentation was lacking. In many instances, the source code was missing. Even when changes could be made, the time it took to test them was taxing on the IT staff.
Just to Save Two Bytes!
The problem originated with punch cards that go back to the early 1900s. In order to cram an entire order or customer record into a single punch card with 80 or 90 character columns, the year was shortened to two digits. Why waste two columns for "19" when it was going to be "19" for a very long time. When punch card systems were converted to magnetic tape in the 1960s, and there was ample room to convert to four digits, laziness prevailed because 2000 still seemed very distant. Saving two columns (two bytes) in a punch card was appropriate, but not when there was ample storage on tape.
Problems Occurred Even Before 2000
For example, imagine a company wanting to delete customers who had not purchased anything in the previous five years. The program logic would add 5 to the year of the last order and compare the result with the current year. Suppose a customer last ordered in 1995 and the current year were 1996. Add 5 to 95 in a non-Y2K compliant system and the result was 00, not 2000. Since 1996 was greater than 00, the customer would be deleted. See data aging and Year 2038 problem.
|This conference was from the Software Productivity Group, an organization that provided the necessary training to deal with this sticky subject. (Image courtesy of Software Productivity Group)|
|Making a Strong Point|
|Year 2000 compliance software from Isogon was used to test IBM mainframe applications running the MVS operating system. (Image courtesy of Isogon Corporation.)|
|Perhaps Overly Dramatic|
|There was a lot of concern before the millennium that things could get out of hand. However, had the world not spent hundreds of billions of dollars revamping thousands of applications, there would have been many problems. There were only a few.|
|Even Before Y2K|
|Program maintenance is always a problem in this industry. This commentary from PROCASE Corporation was created more than a decade before Y2K. PROCASE provided software that could flow chart a program from its source code in order to make it understandable.|
Copyright © 1981-2019 by The Computer Language Company Inc. All Rights reserved. THIS DEFINITION IS FOR PERSONAL USE ONLY. All other reproduction is strictly prohibited without permission from the publisher.