In-Depth
Top Ten Tricky Year 2000 Problems
We've spent a great deal of time performing Year 2000 health checks, audits, and conversions over the last few years, and we've come across a lot of Year 2000 problems in that time. Some of them are cryptic and difficult to find, other are obvious or just plain stupid! Here's our top ten.
1. Zero century
Our first problem is extremely common, but very difficult to spot. It occurs if you move a century-excluded date into a century-included date. How can this happen? Because even though the application may have been designed with century-included dates, programmers performing maintenance over the years may have used century-excluded ones. The most dangerous aspect of this problem is that it may have been going on for a long time and no one's noticed. That's because most older applications display dates as 6 digits. The application may assume that century-excluded dates are in the 20th century. And they were when first entered. However, when the date changes to January 1, 2000, these dates won't be in their correct century.
The solution is to locate them in the code and then convert the data. An alternative is to add checks for zero centuries in your application and convert the data on the fly.
2. Processing custom dates
Custom dates often cause more Year 2000 headaches than standard dates because they need custom code. For example, data that contains the year and week number as YYWW can give incorrect values as soon as the century changes. If you start with a year and week and want to calculate the previous week number, you have to consider the fact that there are 52 weeks in the year. That is, if you subtract 1 from the week number and get 0, the week number is 52 and you also must subtract 1 from the year.
Here's what happens in the next century because most applications don't take the year into account as well.
Starting Year-Week Previous
Week
Year
Result
Intended
Result
Resulting
Year-Week
9801
52
97
9752
9752
9802
1
98
9801
9801
0001
52
-1
9952
-48
The same problem occurs if you add 1 to the week or add 1 to the year.
Starting Year
Starting Year + 1
Comments
98
99
OK
99
100
OOPS!
If the data is being used for comparisons or sequencing, then it should be expanded to include the century. If not, the logic should be changed to include a year 0 and 100 check in the same way that there's a week 0 and 52 check.
3. Date input format not allowing a century
As we mentioned earlier, most older applications display dates as 6 digits. They also allow only 6 digits to be input. This means that the user can't enter the century. If the application assumes a century default, the user can't enter a date outside this range. Even if the application has a century window, the user can't override it, because there's no place to enter the century.
The solution is to expand the input date format to allow the century. Keep in mind that you still want the century to default in most cases, but the user needs the option of being able to override that default.
4. Comparisons
This is one of the most common Year 2000 problems, so why is it in this list? Because it's not just dates that are compared. Very often, a year is extracted from a date and subsequently compared. Or it's a fiscal year that's compared. Fiscal years are not dates as such, but you'll run into many of the same problems with comparisons and sorting. If you compare a 2-digit year to a literal value, the check will not work as intended after 1999.
If you expand your dates ensure that you extract the century along with the year. If you have non-date year values, either expand them or incorporate windowing into your logic.
5. Manual century addition
There are times when your applications may have to read century-excluded date data from a third-party application. If your processing requires a century, you may be adding the century based on today's date. This works fine until the century-excluded date and today's date are in different centuries.Today's DateCentury-excluded DateCentury-included Date199806169801
21
19980121
20000101
980121
20980121
19991231
000121
19000121
Sometimes programmers add the century by brute force. They hardcode the 19 in the century position or add 19000000 to a 6-digit date. This results in invalid data as soon as the 21st century starts. And it's especially insidious since it may not be easily discovered. At least not until February 29, 2000. Any date editing that takes all the leap year rules into account won't allow a date of February 29, 1900. It wasn't a leap year!
The only way around this one is to examine your code for date-type literals and adjust the logic. As for the former problem, you must duplicate the century logic from the third-party application in your own.
6. Misleading data names
Data names often give us subliminal clues as to what's in the data. If data is named START-CCYYMMDD, we might assume that it contained the century, year, month, and day. And that might have been the programmer's intention.
But if a century-excluded date were moved into it, the name is no longer representative of the content. And remember, the computer doesn't understand the names at all. It's amazing how often we subconsciously assume that the computer knows what a particular word means.
When you're assessing your Year 2000 problem, evaluate all data names, not just those that look like dates, and don't assume either way.
7. Incorrect date extraction
In the same way that maintenance programmers may have taken shortcuts and used century-excluded dates, they may have also assumed that all dates included the century. This often occurs where many different programmers have their hands in an application where the dates are supposed to include the century.
Say a programmer must extract the century and year. If this is accomplished by extracting the first 4 digits, the result is the year and month. Not exactly what was intended. But it can get worse. What if the input date is not in YYMMDD format but is actually a formatted date. For example, if the format was supposed to be DD-MMM-CCYY, then extracting the eighth through eleventh characters would give the century and year. But if that content is actually DD-MM-YY, then the result would be only the year.
8. Special values
Special values are the bane of our existence. Data values that represent processing are a maintenance nightmare. Much better to use separate codes. There are applications that use a year of 99 to mean special transaction timing. Unfortunately, these dates will conflict with calendar dates real soon now. If a date value of "999999" is the special value and is used in comparisons, simply expanding it to "19999999" by adding the century may result in incorrect logic. Say the "999999" means "never process this transaction". If a date is greater than today's date, the transaction won't be processed. If, in the course of conversion, all date values have the current century, 19, added to them, the result would be 19999999. But once past December 31, 1999, this value is less than today's date, so these transactions would be processed.
It's important to understand how the date values are used before blindly converting from a 2 to a 4 digit year.
9. Last day of the month
Calculating the last day of the month on a century-excluded date can be a problem. You'll get different results for February 29 depending on which century is assumed.
Date
Assumed century
Last day of the month
000201
19
000228
000201
20
000229
This is another good reason to expand dates to include the century.
10. Cascading data
These are the worst ones to find if you are not using a tool that keeps track of the search results. A typical cascade is where a date is buried within another data value, for instance an invoice number. Now that's bad enough, since if the date started out as century excluded and is expanded to include the century, the invoice number must also be expanded. However, what if subsequently the date or part of the date is extracted from the invoice number and used for another calculation or comparison. Then that extraction must be corrected as well as the target. And so on.
Not only do you have to trace the dates, but also where they're used and the other data they affect. Then you have to trace the affected data as well. And on and on until you reach the end of the trail. Not doing do leaves your application suspect.
How can you find all the problems?
We hate to raise additional problems just when you think you've found them all. But it's better to check again than risk the wrath of the software gods on January 1, 2000! The trouble is that there are literally hundreds of problems like this, alone and in combination, and to find them all you would need to perform thousands to searches to identify every possible permutation and combination where they can occur.
Thankfully, we used a specialized Year 2000 search tool to find all the above problems within a few hours of us starting our analysis. The tool we used, Cognos PowerHouse Power2000, was designed to help assess and convert Year 2000 problems in PowerHouse 4GL applications. Among other things, it saves the results of each scan for use in subsequent scans. This makes it easy to find things like the cascading data problem.
Find the right tool for your job and uncover those tricky Year 2000 problems!
About the Authors:
Bob Deskin is Power2000 Product Manager and Senior Product Advisor with Cognos Incorporated in Ottawa, Canada. Bob has been with Cognos for more than 16 years, and for the past 3 has been the Year 2000 contact for Cognos' 4GL Products group. Bob can be reached at bob.deskin@cognos.com.
Mike Blackadder is the Principal Year 2000 Consultant for Cognos Limited in the U.K. Mike joined Cognos in 1988 and has used his extensive Year 2000 project experience to help design and build Power2000.