With the year 2000 breathing down our necks, the search is on for the best way to accommodate year 2000 dates in our databases. There are four common techniques for handling year 2000 dates: two-digit encoding/compression, windowing, adding a century field, and full four-digit year conversion. Which method is right for your shop? That all depends on how big your century-date problem is, how much time and labor you can afford to put into the project, and whether you want a temporary or permanent solution. Whichever solution you choose, bridge programs can help you implement it.
One Y2K database strategy involves expressing a four-digit year in an existing two-byte space. There are many ways to perform two-digit encoding. Here are some of the most common ways:
• Change from a decimal numbering scheme to a hexadecimal numbering scheme. A decimal numbering scheme spans 100 years (0-99), whereas a hexadecimal numbering scheme spans 256 years (X'00'-X'FF'). In hex, you would express the dreaded year 2000 as X'64', presuming a base year of 1900. If you use 1900 as your base year, the hex numbering scheme lets you express dates through the year 2155.
• Change from a decimal numbering scheme to a user-defined numbering scheme. This method, a variation of the hex numbering scheme, lets you define your own encoding rules. Instead of using a base 16 (hex) system, for example, you could use a base 36 system in which the digits 0-9 and characters A-Z represent digits. This technique provides a span of 1296 years in which the year 2000 would be expressed as base 36(2S), presuming a base year of 1900. With 1900 as your base, this method lets you express dates through the year 3195.
• Change to an unsigned packed decimal date representation. This method lets you compress a four-digit year into the two existing bytes by using each byte to hold two digits. Consider the character value 97, which has a value of X'F9F7'. In unsigned packed decimal format, you can express this as X'97'. Because you can compress a two-digit year into a single byte with this method, you can append another two digits, such as X'19' for 19, in the remaining byte. With this new prefix, the four-digit date will occupy only two bytes having the value X'1997'. Note that an unsigned packed decimal number is a user-based scheme and would actually be designated as a character field. Because the AS/400 doesn't support this as a native format, you must code the routines to perform the packing and unpacking of these "numbers."
Encoding/compression techniques are among the least desirable Y2K solutions. They span a limited number of years, even though the range may be adequate for many shops. The encoding/compression is confusing and requires you to change all programs (even those where a two-digit year suffices) to decode dates. Tools such as query products likely won't be able to decode dates in these formats, and exporting dates to and importing dates from trading partners and other outside sources may prove difficult. Depending on the encoding technique you use, you may also have problems collating and indexing data.
Windowing techniques, which presume a four-digit year based on a two-digit representation, let us address a 100-year span of time and change just programs, foregoing database changes (although it's possible to change the database to contain four-digit years and still use a windowing technique in your programs). Two common windowing techniques are the fixed window and the sliding window.
The fixed window method spans a static 100-year range that usually crosses a century boundary. Using a fixed window, the program determines the century by comparing the two-digit year to a set value. OS/400 itself uses this technique: It presumes that a two-digit year in the range of 0-39 falls within the years 2000-2039 and that a two-digit year greater than 39 falls in the years 1940-1999.
Applications can define the beginning and ending points for the 100-year span, thereby providing some flexibility. However, our static 100-year span of 00-99 didn't cross the century boundary, thus obscuring the fact that this is a windowing technique.
The sliding window technique, like the fixed window technique, spans a 100-year range, usually crosses a century boundary, and lets us determine the century by comparing the two-digit year to a particular value. However, this technique differs in that the 100-year range is dynamic, or sliding, letting us define the beginning and ending points of the 100-year range in terms of the number of past and future years. We could choose 45 years past and 54 years future, for instance, so that in 1997, our applications could handle the years 1952-2051. In 1998, the range of years our applications could handle would slide to 1953-2052.
Note that the Integrated Language Environment provides mechanisms that use the sliding window technique via built-in date/time service routines, which you can use instead of writing your own. For more information on these ILE services, see ILE CEE* date APIs in the System API Reference.
Like encoding/compression techniques, windowing techniques are temporary. You still have problems with exporting dates to and importing dates from outside sources as well as collating and indexing problems.
Adding a Century Field
You can also simply add a single byte to your date field to identify the century. Typically, you'd use the digits 0-9 to represent 19-28. For instance, "0" would represent 1900, "1" would represent 2000, and so on, with "9" representing 2800. This technique prevents additional DASD consumption by replacing the leading zero of a seven-byte packed date field with the one-byte century indicator when dates are stored in seven-byte packed fields.
Although adding a century field can somewhat remove ambiguity from dates, it's a weak implementation. You must change date fields in both the database and your programs. The method also limits the number of years it addresses and complicates date exchanges with trading partners and other outside sources.
Full Four-Digit Year Conversion
A full four-digit year conversion is widely considered the only complete and permanent solution to the century-date problem (that is, until the year 9999). Although this conversion requires you to change both the database and your programs, it offers numerous benefits.
When you change from a two-digit year to a four-digit year representation, you remove all ambiguity from dates. Plus, you can now participate in the world of international standards for date representation and, thus, more easily share date information with outside sources. You can also be sure your collating and indexing functions will work properly.
Among those who support full four-digit years, debate rages about the format a four-digit year date should take: native date fields or the more customary numeric or character formats. The more important issues, however, are finding all the date fields that need to be changed and devising a management plan for expanding them.
Bridging the Centuries
Once you've selected the right method for your situation, you can use bridge programs to convert data from one format to another. Typically, a bridge program defines the following:
• Input date format and encoding technique
• Output date format and encoding technique
• Logic to convert from the input format to the output format
You can use bridge programs at execution time or during database conversion. If you use the programs at execution time, the conversion occurs each time the date is accessed and conversion is necessary. Just a cautionary note: The execution-time bridge program will add complexity and performance penalties to your processing. For these reasons, and because this type of bridge program can become permanent production baggage, be very careful when choosing a bridge program methodology. On the other hand, if you use a bridge program for database conversion, the program simply reads all records in a file, performs the conversion once, and stores the newly formatted date.
"Triggering the Y2K Conversion," shows how you can use triggers as bridge programs to implement a full four-digit year expansion while continuing to process with existing programs.
The Final Assessment
Each strategy for handling year 2000 dates has its own set of strengths and weaknesses. Examine your situation carefully and then select the method that best meets your needs - but don't be too long about it.
Gary Guthrie is a technical editor for NEWS/400 and a senior consultant technical analyst at Storage Technology Corporation in Keller, Texas. You can contact Gary via CompuServe (Gary_Guthrie) or e-mail (email@example.com).