Jim,
We have a couple of systems that use two position dates, and we simply inserted a few lines of code into each program (a subroutine actually), that says if the length of the year is two, then, if the year is greater then 50, add 1900 else add 2000. This works for most logic, display, and printing functions (assuming it will fit on the screen or report), but you are correct when it comes to sorts and date
keys.
This is the same technique that my client used for their Y2K remediation, except we used 1970 as our pivot year. Interestingly enough, some of their other systems used different pivot years, 1920 and 1950. They are going to have to stay on top of these different window periods when they share information. This shouldn't be a problem for a couple of more decades. Hopefully someone will remember this discrepancy 20 years from now.
There is also a very subtle error that can occur when you use this technique. Most of our dates are kept in numeric fields and these fields are not always populated. For example, fields that contain an end date may not be populated until sometime in the future, so the numeric date field is initialized to zero. When you test only the year field for a value of zero, you add 2000 to year field and end up with a date of 20000000 (YYYYMMDD).
Obviously this is not correct. It has resulted in both program crashes and incorrect results in our testing. The crashes were caused by some rather creative code that some programmers added to the programs to deal with the oddities of date math. If you use this technique, please be sure to test your systems thoroughly.
Jim, I read the link that you included in your posting to me. I enjoyed the reading the posting but I have several comments about the paper. When I have some more spare time, I will post my comments on this site.
B.K.
|
