Also called the year 2000 problem or the millennium bug (even though it is not actually a bug), a computer problem that was expected to affect older hardware and software on January 1, 2000. Similar problems were expected to arise on related dates, particularly September 9, 1999, and February 28, 2000.
In the early days of programming, system and disk memory were expensive and had to be carefully optimized. Saving 2 bytes by representing the date 1954 internally as the two-digit number 54 yielded significant savings on a system with limited RAM. This type of “good programming practice” continued even into the mid-1990s. And even though early programmers were probably aware of potential Y2K problems, no one expected programs developed in the 1970s and 1980s to continue being used into the next millennium.
An estimated 180 billion lines of COBOL code have been written for mainframe environments in business, industry, and government, and much if not most of this code had the potential to be affected by the Y2K problem. The problem was not limited to the mainframe arena - it also affected server and desktop operating systems and applications on UNIX, Macintosh, and Microsoft Windows platforms, affecting hardware BIOS programming, operating systems, application software, custom code, macros, and data files. The problem was enormous in scope and well publicized. Government and public agencies, enterprise-level businesses, and software and hardware vendors have devoted extensive resources in recent years to ensure that systems functioned properly on and after January 1, 2000.
The most common PC hardware-related issues associated with Y2K related to the real-time clock (RTC) chip, which in most PCs uses only two digits to represent a year, and the BIOS routing, which is stored in flash ROM. If the BIOS did not contain code to roll over the century from 19xx to 20xx on January 1, 2000, the operating system would see the date 1900 when the user first turned on his or her PC in the year 2000. In some systems, this problem could be fixed with a BIOS upgrade, while other systems have had to be replaced with Y2K-compliant hardware.
Some experts might have advised you to test a system’s hardware compliance for Y2K by setting the date to 11:59 p.m. on December 31, 1999, and observing what happened when the date rolled over. This approach might have been acceptable for testing certain kinds of desktop systems, but it could be extremely dangerous on a network server. For example, on a server that incorrectly rolled over its date, date-licensed software might have expired or administrators might have been locked out of the system.