Chicago-Soft
ATTN: TSO Times
One Maple Street
Hanover, NH 03755
(603) 643-4002
information
@tsotimes.com

Brainstorming About the Rough Weather Ahead
Some Thoughts About the Date Crisis Problem

by Alan Glass

You say that, with the coming of the year 2000, there is a date crisis on the way? Everyone's solution is, of course, that two-digit years should become four digit years. In fact, not only does everyone assume that this is the correct solution, but we see advocacy of this as an enterprise standard. We also see a lot of scolding of IS folks for not implementing this solution a long time ago. ("IS people were trying to save storage space when storage was expensive, and that's why they whacked off two digits from the year"). As if no one but IS people were writing dates in two-digit form! EVERYONE uses two-digit dates, not just IS people.

But that's not the point here. The point is that the four-digit solution may not be the best solution after all. Your IS shop might be the better for some post-four-digit thinking.

Here is the basis for the ideas that follow: One of the problems with the four-digit date is that it consumes additional file/database space and demands that all such files/databases be reallocated and rewritten.

It is possible to avoid at least the additional space/reallocation problems, and perhaps the rewrite problem. Here are thoughts on how:

* Continue to use the two-digit date as is. But, in the logic of the program, build a test case to decide whether the two-digit date is pre- or post-millennium. You could assume that, for example, all dates smaller than "70" were post-millennium. Then such dates could, within the program (not in the database) be represented as 2000+date(other dates would be represented as "1900+date" as now). This solution does not even require that the file/databases be rewritten -- existing dates are perfectly okay. Note also that the date transformations could happen either at the point of inputting the data, or at the point of each use of the date.

There is a big problem with this solution, whatever date is chosen as the breaking point ("70" in the example) can cause two problems. The first is that your database might still contain some legitimate pre-1970 dates, and those would be erroneously interpreted. The other is that come 2070 or thereabouts, the problem occurs all over again. So, this decision is to be used with care and with a thorough understanding of the program to be modified, and its future.

* Continue to use the two-digit date but make it modulo some year. For the non-mathematically inclined, that means make the date an offset from some base date. For example, assume that 1970 is a platform on which all dates could be based. The 1996 would be represented as "26", the offset from 1970. The big benefit here comes from the fact that nothing magic happens in the year 2000. That would be represented as "30", not taxing the two-digit form at all. Also, some transformation would be needed for these dates, at the very least at the point of display and/or printout. But at the point where date subtraction occurs, no transformation would be needed.

There are, of course, problems with this approach. A knowledgeable database person would need to make sure that there were no pre-base-date dates in the files. And the fundamental problem occurs again when we hit base date +99, in this case the year 1970+99=2069.

Both of the approaches described above simply postpone the date crisis -- in the vicinity of 50 to 75 years from now.

* Continue to use the 16 bits allocated to the two-digit solution, but represent the date in binary format. The key to this solution is that 16 bits can support much larger binary numbers than decimal ones. 2**16 is 65,536 ("64K"), plenty large enough to handle all the years we can imagine from here on, and well beyond the 10,000 limit of the four-digit approach. This solution won't work if your dates are represented in packed decimal, a form that uses only four bits per digit. 2**8=256 is nowhere near large enough for the dates in question. Also, most good programming languages make binary a convenient representation to use. Some sort of "COMPUTATIONAL" declaration is needed in COBOL for example.

The only problem with this approach is that a date transformation, analogous to those discussed, would be necessary. The transformation would be trivial. In COBOL, simply assign the binary form to a decimal form: "Decimalyear =Binaryyear"). The transformation would be essential if date arithmetic is currently done using dates in the form YYMMDD. If date arithmetic were done using the year separately, no transformation would be necessary.

Application-Dependent Solutions. We've been deep in the technical trenches. It is important to note that the applicability of these approaches is deeply dependent on the nature of the application and the various ways dates are used in that application. The problems of transformation must be considered, for example, at the point of database construction, database input, date manipulation (including, especially, arithmetic), and date and database output. When all is said and done, for YOUR application these solutions may be more difficult than the "obvious" four-digit one.

All three solve the problems of database space and re-allocation, in that the year is still represented in 16 bits (the first two work even if your years are represented in 8 bits). And the first even solves the database rewrite, because the existing two-digit dates are still legitimate. Each has its problems. And that's where you come in once again. If you don't like these answers to the date crisis problem, don't just go back to the four-digit solution automatically.

Brainstorm a bit. There may be some magic solution lurking out there for YOUR applications.

Condensed and reprinted with the permission of Applied Computer Research. ACR is publisher of The Complete Year 2000 Resource Guide. To order, write Applied Computer Research, PO Box 82266, Phoenix, AZ 85071, call 800-234-2227, or visit the ACR Web site: www.acrhq.com. Mention Chicago-Soft when you order, and receive a 25% discount!

About the Author: Alan Glass is president of Computing Trends, and editor of The Software Practitioner. He can be reached through Applied Computer Research at 800-234-2227.

home · current articles · archives · forums ·
· subscribe · about us · contact us · links