|
|
|
|
|
|
|
Testing is the silent killer in this problem. Because virtually everything must be changed, virtually everything must be tested. You really don't get a chance to isolate the effects of your changes. |
|
|
|
|
|
|
|
|
And yet you must do so. You cannot change everything at once, because there is simply so much to change. Some parts will be changed before others. Hence, it is essential to prevent changes in one part of a system from cascading into parts of the system which have not been changed yet. Still, the communication between parts must be tested, so sooner or later, everything must be tested together, meaning that whole systems must be tested in parallel with their unchanged counterparts. |
|
|
|
|
|
|
|
|
Who has the system resources for such massive tests? |
|
|
|
|
|
|
|
|
The most common technique for fixing the Y2K problem is called the "bridge" or "window." A bridge is simply a code patch that changes the interpretation of two-digit years by adding, in effect, a constant offset to the range of years treated. |
|
|
|
|
|
|
|
|
An example bridge patch fleshes out two-digit years to four-digit years by adding 1900 wherever old code. |
|
|
|
|
|
|
|
|
the bridge patch replaces the line with code such as: |
|
|
|
|
|
|
|
|
if (year_2 > 49)
year_4 = year_2 + 1900;
else
year_4 = year_2 + 2000; |
|
|
|
|
|
|
|
|
The bridge alters the interpretation of two-digit year values in the range from 00 through 49 by adding 2000, not 1900. The input range continues to be 00 through 99, but the range of values to which the inputs are mapped has been moved forward by 50 years: |
|
|
|
|
|
|
|
|
A variant of the window is the "sliding window", which uses the current system date, rather than a constant year, as the dividing line between past and future. The window thus slides into the future, one day at a time. The advantage to this technique |
|
|
|
|
|
