Issue No. 03 - March (1997 vol. 30)
DOI Bookmark: http://doi.ieeecomputersociety.org/10.1109/2.573656
<p>The Y2K problem is real, and it has attracted intense media attention and aggressive vendor response. For whatever reason-- whether they wanted to save precious memory in an era when memory was incredibly expensive, or because they didn't expect systems to last this long, or because they simply didn't recognize the problem-programmers long ago adopted a two-digit convention to represent the year. </p> <p>This convention will cause failures as we approach the turn of the century and beyond. On January 1, 2000, uncorrected software will assume that the maximum value of a year field is 99 and will roll systems over to the date 1900 instead of 2000, resulting in negative date calculations. Incorrect leap year calculations will incorrectly assume that the year 2000 has only 365 days instead of 366. What's more, many date-dependent algorithms and forward-referencing systems are already beginning to fail. </p> <p>Approaches for resolving the problem and managing the risks have tended to focus on how particular tools and vendors can help. This article sets forth the concepts, terminology, and individual aspects of a Y2K effort and then defines a process that an organization can use to address its own Y2K challenge in a forthright and level-headed manner. </p>
R. A. Martin, "Dealing with Dates: Solutions for the Year 2000," in Computer, vol. 30, no. , pp. 44-51, 1997.