The Late Late news. 

  Brought to you by the thoughts of one that created this.

  Todays Late Late news:  people are getting excited over the turn of the century and the computer  Y2K problem that might occur,

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 reason—whether they wanted to save precious memory in an era when memory was incredibly expensive, or because they didn’t expect systems to last this long, or because they simply didn’t recognize the problem—programmers 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.

Y2K Problem Defined

Briefly defined, the Y2K problem involves any or all of these:

• Representing the year as a two-digit number, causing failures in arithmetic, comparisons, sorting, and input/output to databases or files when manipulating date data: incorrect software will assume that the maximum value of a year field is "99" and will roll systems over to "00" which can be mistakenly interpreted as 1900 rather than 2000, resulting in negative date calculations and the creation of many overnight centenarians.
  
• Incorrect leap year calculations will assume that the year 2000 has only 365 days instead of 366. What’s more, although January 1, 2000 is the primary witching hour, many date-dependent algorithms and forward-referencing systems are already beginning to fail due to not properly classifying years divisible by 400; and
  
• Software values involving limited date ranges, including hardcoded values and "magic bullets"
  
• Limits to system date data types in hardware registers

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.

Calculating Leap Years Correctly

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:

1. Years divisible by four are leap years, unless...
   
2. Years also divisible by 100 are not leap years, except...
   
3. Years divisible by 400 are leap years.

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.

Hardcoding and Magic Numbers

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 today’s 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 won’t move but is common to everyone. We will all be competing for scarce resources—COBOL 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 interface—fixes that will have to be fielded simultaneously. Third, instead of the traditional maintenance problem—"Here’s the problem, fix it"—the Y2K problem becomes "Where is the problem and what are the fixes?" Testing, validation, and fielding will consume the lion’s 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