Dave: re: No Y3K problem because code has been remediated to allow 4 digits.
Well, slow down there, pardner!
Since the majority of folks are choosing the "windowing" method for remediation ... because it's less expensive than 4 digit expansion (theoretically) ... then there absolutely WILL be a Y3K problem.
With windowing, the data stays at 2 digits for the year, and a pivot year is used to determine the century value. For example, let's assume a site chooses "50" as their pivot year. If the "YY" value is 50 or greater, then the century value is assumed to be 19. If less than 50, the century is assumed to be 20.
With windowing, we know that "02" means 2002, not 1902.
When the year 3000 (Y3K) rolls around, that assumption will become yet another occurrence of our existing problem. Because of the windowing "rule" we defined, "02" will still mean 2002. So, how do we represent 3002?
There's no such thing as a 3 century window. The code can't handle this change automatically. You have to tell it which century value to assign. 19, or 20, or 30, or 40.
Ain't theory wonderful?
Note that I'm not predicting this scenario to happen. The code we're maintaining today won't be in existence in Y3K.
Of course, that's what I predicted about the code I wrote in the early 70's. It wouldn't be in existence in Y2K. Ask those poor programmers who are now "fixing" the code I wrote back then whether or not my prediction was correct.
Ooooops ...
TED |
