Y2K, also called the year 2000 problem or the millennium bug (even though it is not actually a bug), is a computer problem that was expected to affect older hardware and software on January 1, 2000.

What is Y2K?

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.

  • Until recently, most software (and the BIOS on most PCs manufactured before about 1996) had been written to store date information in a format that uses only the last two digits of a year to represent the year. For example, the year 1960 is internally represented as 60. This date representation issue is most commonly identified as the year 2000 problem because the year 2000 is represented internally as 00, which is the same as for 1900. Most older software does, in fact, interpret the internal date 00 as 1900 instead of 2000. The problem arises when calculations are performed using dates. For example, financial software might calculate that an employee born in 1954 is actually 00 - 54 = -54 years old in the year 2000, and this negative age could lead to such problems as missed paychecks or pension contributions. On a large scale, such problems could have disastrous social consequences.
  • The year 2000 is a leap year because it is divisible by 4000, but some older software applications and hardware BIOS programs do not recognize this fact and, as a result, produce dates that are off by one day after February 28, 2000.
  • Many older software applications use special dates to represent special situations. For example, many older COBOL applications give the date 9/9/99 a special meaning such as “this item is to be saved forever” or “this item is to be deleted after 30 days.” Such applications had the potential to produce unpredictable results after September 9 , 1999.

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.