Date: Thu, 20 Jan 2000 21:20:33 +0530 (IST)
We've all heard of Y2K by now. Some of us even know what it is. For those who don't, here's the executive summary: It's the inability of computers to recognize the year 2000. Some systems see '2000' as '1900', others as '00', and others as some semi-random date in the 20th century. Some weird systems show 1000 or 0000.
Y2K is a problem for systems which need to know the current year in order to carry out some function. Take interest calculations, for example. What is the interest earned over a period from 1998 to 2001?
o Y2K compliant systems will come up with the correct answer, based on a period of 4 years.
o Non-compliant systems will come up with various incorrect answers based on periods like -97 (01-98) or -98 (1900-1998) years. Some might even reach the correct final answer but have the wrong year values: 1998-19101. Websites are becoming notorious for the latter, due to the way Perl handles years.
This is mostly caused by poor programming, or hardware limitations, or both. In modern systems, this can usually be blamed on poor programming or a need for backward compatibility.
In many cases, however, the problem is not that bad. Some types of systems depend on the time, but not necessarily on the date. Embedded controllers, for example, might only need to know elapsed time. This is done by counting seconds or minutes or years elapsed. These systems usually do not take the current date and subtract a stored date.
On the other hand, Y2K problems have turned up in some of the United States' Pentagon satellites. It was recently revealed that some mapping satellites lost contact with ground stations and that particular network was running below capacity. No nukes were launched.
Then there was the video cassette rental shop that nearly charged a customer something on the order of ninety thousand dollars. But overall, the effects of Y2K were much less than predicted by the doom-sayers.
Some people have taken this to mean that there was no need to panic, and that the millions of dollars of preparation were wasted. Not true. It was precisely because of this preparation that there were no major disasters. Many man-hours were spent in weeding out critical code. Even know, there are millions of lines of code on the web that are causing various sites to report the year as 19100.
There is a lesson to be learned here. Hard-coded limits are bad. A good programmer should also allow for all foreseeable exceptions (following Murphy's law, one notes that not all exceptions are foreseeable). While the Y2K bug was foreseeable, the fact that legacy code, hardware, and programming practices would still be in use was not. We do know that Unix systems have a time counter which might roll over sometime in 2038, but the problem should either be fixed or we'll all be on 64-bit machines by then. Let us hope so.
PS: A strange manifestation of a similar bug was reported in a broadcast on an American news network, where the "millenium" countdown proceeded as follows: ... 04:02, 04:01, 03:00, 03:59, 03:58 ...
Satya, January 1900.
Copyright © Satya 2000. All Rights Reserved.