Start Fixing Year 2000 Problems Now! Applications that depend on dates--and you'd be surprised at the many ways they do--are already beginning to fail. This is one project you can't put off. By Joe Celko
"The alternative to addressing the Year 2000 will be going out of business." That's what Kevin Schick, research director for the Gartner Group, says. He's not a lone voice. If you've been watching your junk mail or reading the odd articles in the newspapers and the computer trade press, you've been hearing about the "Year 2000'' or the "Millennium" problem. Don't believe everything you read. The coverage is not usually too deep and generally consists of anecdotal horror stories about programs that used a two-digit year (year-in-century) format and blew up. That sort of shallow story doesn't scare management and programming staff very much--we've all seen programs crash before. In fact, the situation is much worse. According to published reports, for example, ITT Hartford estimates the cost of adding the century years to dates in its computer systems will cost upwards of $20 million. That's a scary number. If you're not sweating now, read on. We want you to leave this article properly fearful and motivated--and appropriately armed. Why will the year 2000 be catastrophic for most computer systems? For three major reasons: 1. The year 2000 has a lot of zeros in it. 2. The year 2000 is a leap year. 3. The year 2000 is a millennium year. A Battle Plan for 2000 THREE BIG ZEROS I like to call Problem No. 1--the zeros in 2000--the "odometer problem" because it's in the hardware or system level. Although it may seem at first glance that this is the same as the millennium problem--when date arithmetic becomes invalid--in fact, it's not. All of your computers have a system clock, and many of those clocks will roll over like a car odometer that's reached its limit and will indicate the year as 1900 (or something else other than 2000), which will then be picked up by application programs. 
Another version of this problem occurs when the system clock is based on a displacement of a base date. Such systems (Digital Equipment's, for example) will return to the base date at the Year 2000. This problem resides where you can't see it--in hardware and operating systems related to the system clock. Information about such problems is very incomplete, so you will need to keep yourself posted as new releases of your particular products come out. Another subtle form of the zero problem is that some hashing and random-number generators use parts of the system date as a parameter. Zero is a perfectly good number until you try to divide by it and your program aborts. The problem cuts across many types of hardware. Unisys 2200 mainframes, for example, will fail on the first day of 1996 because the 8th bit of the year field--which is a signed integer--will go to 1. The vendor has some solutions. Do you know what other hardware uses this convention? You might want to look. IBM will bring mainframes based on the S390 processor (3090E and newer) into "Year 2000 compliance," as long as you have at least MVS version 5.1. For the AS/400, IBM offers a date-windowing technology that pushes the problem forward to 2040, but doesn't fix it completely. The real killer will be Intel-based PCs. When the odometer wraps around, DOS jumps to 1980 most of the time, and sometimes to 1984, depending on your BIOS chip. Windows 3.1 jumps to 1900 most of the time. You can test this for yourself. Set the date and time on your PC to 1999-12-31 at 23:59:30 Hrs, and let the clock run. What happens next depends on your BIOS chip and version of DOS. The clock display may show "12:00AM" and the date display "01/01/00," so you think you have no problems. However, you could find that you have newly created files dated in 1984 or in 1980. Surprise! This problem is passed along to application programs, but not always the way you would think. Quicken version 3 for the IBM PC running on MS-DOS 6 is one example. As you'd expect, directly inputting the date 2000-01-01 through the DOS DATE command results in the year resetting to 1980 or 1984 off the system clock. But strangely enough, if you change the date to 1999-12-31, the next day Quicken interprets the change as 1901-01-01 and not as 1900. Although PC manufacturers are beginning to address this problem (IBM promises its 1996 machines will handle 2000), older machines will require a DATE command be executed every time the machine is turned on. LEAP YEAR Problem No. 2 always seems to shock people. You might remember being told in grade school that there are 365.25 days per year and that the accumulation of the fractional day creates a leap year every four years. Not quite. By convention, the first year of any century is not a leap year. Except for every fourth century. And guess what--2000 is it. Lots of programs were written by people who didn't know this. I don't mean COBOL legacy programs in your organization; I mean packaged programs for which you paid good money. The date functions in the first releases of Lotus, Excel, and Quatro Pro did not handle February 29, 2000 correctly. Lotus simply made an error, and the others followed suit to maintain "Lotus compatibility" in their products. Currently, MS Excel For Windows, version 4, shows correctly that the next day after 2000-02-28 is February 29. However, it thinks that the next day after 1900-02-28 is also February 29 instead of March 1. MS Excel For Macintosh doesn't handle the years 1900 1903. Have you checked all of your word processors, spreadsheets, desktop databases, appointment calendars, and other off-the-shelf packages for this problem yet? Just key in the date 2000-02-29, then do some calculations with date arithmetic and see what happens. With networked systems, this is going to be a real nightmare. All you need is one program on one node in an application system on the network to reject Leap Year Day 2000, and the whole network is useless for that day and transactions might not reconcile for some time afterwards. How many nodes do you think there are in the ATM banking networks in North America and Europe? THE MILLENNIUM I saved Problem No. 3 for last because it's the best known one in the popular and computer trade press. Programmers have not been keeping true dates in data fields for a few decades. Instead, they've been using one of several year-in-century formats. These will not work in the last year of this millennium (the second millennium of the Common Era calendar ends in the year 2000, and the three millennium begins on with the year 2001--that's why Arthur C. Clarke used it for the title of his book). If only we had been good programmers and not tried to save storage space at the expense of accuracy, we would have used ISO standard formats and not have these problems today. Programs have been doing arithmetic and comparisons based on the year-in-century and not on the year. A 30-year mortgage taken out in 1992 will be over in the year 2022, but when you subtract the two year-in-centuries, you get (22-92)= -70 years. This a very early payoff of a mortgage! Inventory retention programs are throwing away good stock, thinking it's outdated--look at the 10-year retention required in the automobile industry. Lifetime product warranties are now being dishonored because the service schedule dates and manufacturing dates cannot be resolved correctly. One hospital has already sent a geriatrics patient to the children's ward because it only keeps two digits of the birth year. Imagine your own horror story. But the problem is more subtle than just looking for date data fields. Timestamps are often buried inside encoding schemes. If the year-in-century is used for the high-order digits of a serial numbering system, then any program that depends on increasing serial numbers will fail. Those of you with magnetic tape libraries might want to look at your tape labels now. The five-digit label that's used in many mainframe shops for archive and tape management software also follows the convention that programmers use the retention date of 99365 if they want a tape to be kept indefinitely--which is actually 1999-12-31--because the routine checks the last three digits to see that they are between 001 and 365. This method will fail at the start of the year 2000 when the retention label has 00001 in it. So the scope of the Year 2000 problem is much broader than you might think. Face it, unless you take action now, 2000 is not going to be a good year for data processing. // Joe Celko is an Atlanta-based senior consultant with OSoft Development and a columnist for DBMS magazine.
| 
