|Home > Y2K >|
The following Y2K material has been kept available by MITRE for historical purposes only and has not been updated unless noted.
What is the Y2K Problem?
Overview of Problem
Studies to define the scope of the Y2K problem and the costs to fix it have produced widely varying results, causing confusion and concern. The problem has caught the media's attention and the public's imagination, and it has stimulated aggressive vendor response. Almost all computer-based systems will be adversely affected by the arrival of the Year 2000 (01/01/2000), unless action is taken now to replace, update, or change components of these systems to eliminate or otherwise mitigate the effects of this event. Fixing and testing the problem poses a significant problem for system and particularly software maintenance.
For whatever reasonwhether they wanted to save precious memory in an era when memory was incredibly expensive, or because they didnt expect systems to last this long, or because they simply didnt recognize the problemprogrammers long ago adopted a two-digit convention to represent the year. This convention will cause failures as we approach the turn of the century and beyond. The problem has precedent: Few realized that the IBM 360 could not handle dates past 31 December 1969 until 360s all over Europe started failing at midnight local time. As the failures progressed around the globe, following the timezones, IBM identified the problem and was able to provide its American and Asian customers with a temporary fix by telling them to lie to their computers about the date. Meanwhile, IBM proceeded to create a longer-term patch for the problem.
Unfortunately, the problem is not isolated to programming errors caused by the use of the two-digit year coding scheme. The year 2000 presents a "triple witching hour" of potential traps for designers and coders. In addition to the two-digit year coding, there are distinct issues surrounding the use of the six-digit date representation, and still other risks caused by the calculation of the leap year. And just to make matters worse, January 1, 2000 falls on a Saturday. Problems caused by coding errors may not be discovered until the next regular working day, allowing enough time for the errors to inflict a great deal of damage.
Briefly defined, the Y2K problem involves any or all of these:
These can be more fully described as follows.
Two-Digit Year/Six-Digit Date Coding
Use of two digits to represent the year is expected to be the most common cause of year 2000 failure. Applications that require the user to enter a date routinely present a two-digit field to the operator in an attempt to reduce the number of keystrokes needed to enter data. Failure to append the correct century to the value after input results in an inability to distinguish between 1900 and 2000. For the most part, this shortcoming was not an issue earlier in the century; however, as the year 2000 approaches, the capability to differentiate between dates in the twentieth century and dates in the twenty-first century will be a necessary requirement for a successful system. This is also referred as six-digit date coding, since two digits are often used for each of the month and day fields as well as the year field. Six-digit date coding is common in administrative information systems. Planning and scheduling systems, human resources systems, financial and billing systems, and many other programs use the convention. This coding method is typically used where the application is attempting to determine which of two dates is earlier in time, or if a certain deadline has passed. These tests are frequently coded with a single inequality statement used to compare the two six-digit dates.
The second complicating factor in the millennium problem is the leap year calculation. It is evident that many people are unaware of the rules for determining whether the current year is a leap year. In fact, one user wrote a Software Problem Report against the run-time library routines for an operating system complaining that the year 2000 was being incorrectly identified by it as a leap year.
The year 2000 IS a leap year. The three rules which the Gregorian calendar uses to determine leap year are as follows:
Therefore, the year 2000 is a leap year according to rule number three.
For some additional information on leap years and how they came about, please see the leap year explanation.
The third area of problems comes from hardcoded values in software routines such as "19" for the implied century and/or use of "99" and "00" as reserved values meaning "never delete this" or "this is a demonstration account," respectively (sometimes called "magic numbers") which limit the range of year values and may cause date comparisons to fail or pollute output values. Other magic number dates include: 9/9/99, 99/99/99, 1/1/1, 1/1/11, 6/9/69, 6/7/89, 1/23/45, 6/6/66, 7/7/77, 8/8/88, and 12/31/99. For a list of these and other dates to test around, please see our Comprehensive List of Potential Y2K Problem Dates. Although for your Year 2000 testing, you may want to focus on those involving 99 and 1 in the years' position.
Limiting Date Range Size
The fourth and final area of problems is platform limitations. Specifically, the internal date representations of COTS hardware and software components, software date data types which are stored as an increment over some base date, may roll over and fail due to the storage register filling up. This is the problem facing many Global Positioning Satellite receivers when their internal week counter rolls over its 10-bit counter on August 21, 1999. Additionally, not all PC BIOSs are Year 2000 compliant. Older PCs may require a BIOS upgrade (a process often called "flashing the BIOS" to existing hardware with the capability), or must be patched / manually set to operate properly for the Year 2000.
How Vast is the Problem?
Just as todays railroad uses a rail standard derived from the width of a Roman chariot, modern computer systems inherit their default conventions from the mainframe era, when it was common practice to encode the year as a two-digit field. After all, workstations and PCs were initially built to augment mainframe systems and use their data. So this mainframe practice has spread throughout our systems. The Y2K problem is very widespread: It affects hardware (BIOS, real-time clocks), embedded firmware, languages and compilers, operating systems, random number generators and security services, database-management systems, transaction-processing systems, EDI and banking systems, spreadsheets, PBXs, phone systems, and more. Y2K is not simply an IS problem: Although the majority of Y2K problems are located in information systems, the sad truth is that any system anywhere that uses dates may be threatened. In addition, we've all been striving to maximize the use of Commercial Off-the-Shelf (COTS) platforms, operating systems, and applications in all of our new or updated systems. However, the effects of doing this may turn out to be another source of disruption that needs to be managed when it comes to the Year 2000 problem. The interdependencies of organizations using C4I systems through rapid data exchanges and multiple interfaces will certainly lead to scheduling, testing, and coordination problems. It is naive to assume that new applications and systems are immune to Y2K. It was only late last year that a new version of Quicken, a popular personal finance package, was released that could handle dates beyond 1999. At the January Federal Interagency Y2K meeting, it was reported that the National Institutes of Health received a shipment of brand-new PCs containing three different versions of BIOS, two of which failed to correctly handle the century transition.
What Makes It Unprecedented?
Although similar to other software problems, such as the four-digit zip code extension, the Y2K problem has some peculiarities that make it more than a standard maintenance problem. First and foremost, it has a deadline that not only wont move but is common to everyone. We will all be competing for scarce resourcesCOBOL programmers and testing personnel, for example. Second, it affects every system that has an external interface, because these systems could be inundated by the proposed changes from systems with which they interfacefixes that will have to be fielded simultaneously. Third, instead of the traditional maintenance problem"Heres the problem, fix it"the Y2K problem becomes "Where is the problem and what are the fixes?" Testing, validation, and fielding will consume the lions share of the costs associated with fixing the Y2K problem. For some, the solutions may be influenced, complicated, or dictated by legislative or regulatory mandates. Other regulations will simplify fielding a fix. For example, the new US acquisition regulation interim rule mandates the use of Y2K warranty language, defining compliance as "information technology that accurately processes date/time data (including, but not limited to, calculating, comparing and sequencing) from, into and between the [20th and 21st] centuries, and the years 1999 and 2000 and the leap year calculations."
For More Information
For a more thorough discussion of the Year 2000 problem and the compliance process, please see the October 1997 Crosstalk magazine article Dealing with Dates: Solutions for the Year 2000. For more information on estimating the problem and its ramification on information systems, see A Framework for Estimating the Cost of Fixing the Year 2000 Problem. For a complete listing of all downloadable material we have available from this website to help you with the Year 2000 problem, please see Y2K Material Available for Downloading.
Page last updated: January 27, 1999 | Top of page
Solutions That Make a Difference.®