What Problems Did the Y2K Bug Present?

Before we crossed into the new millennium, rumors were rampant that as the clock struck midnight of December 31, 1999, electricity would shut off, planes would fall from the sky, nuclear missiles will be launched, and the world would go into a state of chaos.  None of this actually became reality, but there were problems caused by the bug, and there were countless problems which would have been caused if the problem was left unattended. 

Some problems which do not seem like that big of a deal could have results which are surprising.  January 1st, 1900 was on a Monday, so computers might indicate that it's Monday, not Saturday.  Year 2000 is also a leap year, but 1900 was not.  This means that computers may go from February 28th to March 1st and completely miss February 29th.  While these don't seem like major problems, there could have been serious consequences had the bug not been fixed.

Consider the following scenario. Two planes are approaching J.F.K. Airport in New York on February 29th.  Plane A has software which is Y2K compliant, but plane B's software is not compliant and thinks the date is really March 1st.  Plane A sends a request to land on runway 1 at 2:00, February 29th.  Plane B sends a request to land on runway 1 at 2:00, March 1st.  The computers at the airport obviously see no conflict with these two requests, and grants both planes permission to land at the requested times.  Both planes then attempt to land on the same runway at the same time.  Although this is just a hypothetical example, similar situations would have been common if huge efforts were not made to fix the problem before the turn of the century.

Another, possibly more realistic example is with banks.  Often times, for reasons such as interest payments, a bank needs to know how long a certain account has been open.  To do this, the computer simply subtracts the date the account was opened from the current date.  What would happen if, in January 2000, this calculation was done for an account opened in 1999.  The computer would then find that the account had been open for -99 years.  It is impossible to tell how the software would react to having a negative number. 

As we have seen in the previous example, the bug can show its face in many ways.  Even though one of the planes was compliant, it suffered because plane B was not.  Another problem which is probably the greatest reason that the results of the Y2K bug seemed so unpredictable is the fact the every computer system depends on many different subsystems.  A company which produces software for a Windows platform has to rely on Windows being Y2K compliant.  Interdependent systems make it nearly impossible to determine what systems will fail and what systems are compliant. 

A perfect, real life example is that Microsoft Visual Basic versions 3.0 and earlier are not year 2000 compliant.  Any programs coded and compiled using these version of Visual Basic has to either be rewritten, or at least examined for system calls or other code which may cause problems.  Microsoft Internet Explorer and Hotmail programs had problems with a  'Get Year' command often called by web-page code.  This command returns only a two-digit year.  To get a four digit year, the 'Get Full Year' command must be used.  Failure to update code caused many web-pages to display the date as 3900.

Detecting the problem is just a small part of the solution.  The vast majority of computer hardware and software created since the 1960's has to be rigorously checked and tested for Y2K compliance.  Most of this software uses dates in some way, and thus probably isn't compliant.  The first step which needed to be taken was to fix the bug in the program.  This is only the beginning of the battle however.  Once the problem has been fixed, the fix needed to be installed at all locations using the non-compliant systems.  Lack of upgrading caused many of the problems experienced as we entered the 21st century.