year 9999 (when the Y10K panic will hit, and we will have to convert all the COBOL code yet again)-right?
Unfortunately, we will have opportunities to apply the methods of Y2K repair and testing well before the year 10000. In the United States, the set of possible telephone numbers probably will be completely allocated sometime in the first decade of the 21 st century. The U.S. will have to convert from the present ten-digit system, which will likely be painful and full of errors. Some time within the first two or three decades of the 21 st century, the U.S. will also run out of Social Security numbers.
Both the telephone numbers and Social Security numbers are pervasive, which means that major data conversion efforts will be needed-similar in the types of activity and possibly similar in size to the Y2K effort.
There are more lurking date problems too, such as the resetting of the Unix clocks in 2038. The Unix problem does not affect 64-bit systems, at least not for a very long time, and some people are banking on not having the older 32-bit Unix systems around when the date rollover happens. Back in the 1980s and early 1990s, though, people said that there would be no Y2K problem because all the old systems would be replaced long before 2000. Some hapless Unix system administrators will no doubt be feverishly installing fixes minutes before midnight the last day of 2037.
Perhaps the most significant thing about Y2K is not that it was perceived to be a crisis and that it was managed in an acceptable manner. There have been many crises in human history. But Y2K was the first worldwide crisis that was software-driven. There undoubtedly will be more.