What Is Your Opinion On Potential Solutiongreenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread
The talk show host on a local Metro Atlanta radio station posed a question he had heard about (didn't get his source) regarding a potential temporary solution to the Y2K problem. The suggestion was to replace the existing numercal digits for the months of the year as follows: January - 13; February - 14; March - 15, etc. At the same time, "99" designated for the year would continue to be used on into the year 2000. Under this scenario, you have January 1, 2000 shown as 13-1-99; February 1, 2000 shown as 14-1-99; March 1, 2000 shown as 15-1-99, etc.
Will computers accept such commands? What is your opinion or knowledge regarding such a suggestion?
-- Patricia P. Fitch (firstname.lastname@example.org), August 13, 1998
Heard that also: nope, won't work. 1) If there is a data entry process, checking for invalid entries will prevent the entry of the number. (If there is no "invalid entry" rountine, then the program likely has other problems as well.) 2) Exporting the "bad" month into other computer files will scamble those files, if (1) the second computer isn't ready to receive the bad date (replacing the real date), or can only accept good 01-12 dates, or is already y2k compliant and so has to be re-re-corrected to accept newly "broken" dates.
3) many internal routines are fiscal (gregorian or julian) dates, and so have to translate to/from conventional calenders anyway. So even programs that could work this would suddenly "break" other programs relying on their dates.
Again, the simplistic idea must be avoided. It requires more programming to do the work around than to correctly fix the problem. Bottom line: Just because a person can "read" the number and inteligently (intuitively) interpret it to mean soemthing else, doesn't mean a companuter can do the same thng.
For example, you can understand my atrocious typing, but a program trying to "run" these words as "sentences" would fail, until I had corrected all the errors.
-- Robert A. Cook, P.E. (email@example.com), September 05, 1998.