Cheeky:
Thanks for the USA Today link to the article on windowing. Yet another thing to bother those of us in the know about this mess.
To truly fix the Y2K problem you have to expand all of your dates into four digit years. Not just in the code. In every stored record that you have. Even if you have already taken up your 80 byte (or whatever) fields. For all of you non-geeks, that is like having completely filled billions of boxes with blocks, no more room, and being forced to go back and add more blocks. Your only recourse is to get billions of new boxes. Not an easy thing to do.
It is precisely this date expansion problem that led to the Department of Defense nixing the Cobol guys' attempt to establish four digit dates as standard in the 70's. DOD was already the largest user of computers, and they didn't even want to think about having to go back and expand the dates in all of their stored records. Huge opportunity lost. THe de facto two digit date standard in Cobol crept into other languages, into common practice. Everyone just assumed that someone would 'take care' of this mess.
And the rest, they say, is history.
So we have this windowing thing. "If the number is 29 or less, put it in the 20th Century'. If not....
And, guess what, there is absolutely no agreement or consistency in windowing. So two 'Y2K compliant' computers can fail when they send each other transactions.
Oh, to get back to my favorite messed up company, Microsoft has used different windowing strategies for their Access database and the Excel spreadsheet. Yep. I'll send you a reference.
So a user of Microsoft's Y2K compliant Access database can send a transaction to Microsoft's Y2K compliant Excel spreadsheet and it will fail because Microsoft's Y2K fixes classify it in different centuries.
This is what Bill Gates calls fixing the problem. And so do a lot of other people. Maybe we should coin a new phrase 'well that depends on what the meaning of Y2K compliant is...is" |
