It was thought Computer programs could stop working or produce erroneous results because they stored years with only two digits and that the year 2000 would be represented by '00' and would not follow 1999 (i.e., '99') in numerical sequence. This would cause date comparisions to produce incorrect results.
Y2K is the common abbreviation for the year 2000 problem.
The underlying programming problem was quite real. The problem started back in the 1960s, when computer memory and storage were scarce and expensive. At the beginning, most data processing was done on [punch cards]? which represented text data in 80-column records. Programming languages of the time, such as COBOL and RPG, processed numbers in their ASCII or EBCDIC representations. They occaisionally used an extra bit called a "zone punch" to save one character for a minus sign on a negative number, or compressed two digits into one byte in a form called [binary-coded decimal]?, but otherwise processed numbers as straight text. Over time the punch cards were converted to magnetic tape and then disk files and later to simple databases like ISAM, but the programs usually changed very little. Popular software like dBase? continued the practice of storing dates as text well into the 1980's and 1990's.
Saving 2 digits for every date field was a significant savings at that time. Most programmers then did not expect their programs to be used for many decades, so it was not considered a significant problem. Programmers started recognizing it as a looming problem in the 1980s, but inertia and apathy caused it to be mostly ignored.
Storage of a combined date and time within a fixed binary field is often considered the best alternative, but is still a significant issue. Such date and time representations must be relative to a defined origin, such as the date of the first operating system. Roll-over of such time date systems are still a problem but can happen at varying dates. For example, the typical Unix timestamp stores a date and time as a 32-bit integer number representing the number of seconds since January 1 1970, and will roll over in 2038. Programs like Microsoft Excel store a date as a number of days since an origin, often called a Julian date. But even Excel has different origins in different releases of the program (some starting at 1900, some at 1904).
Another related problem for the year 2000 was that it was a leap year converse to the usual rules of once per four but not for a century.
Some industries started experiencing problems related to it early in the 1990s as future-date-handling software started processing dates past 1999. For example, in 1993, some people with financial loans that were due in 2000 received (incorrect) notices that they were 93 years past due. As the decade progressed, more and more companies experienced problems and lost money due to erroneous date data. As another example, meat-processing companies incorrectly destroyed large amounts of good meat because the computerized inventory system identified the meat as expired.
As the decade approached 1999, identifying and correcting or replacing affected computer systems or computerized devices became the major focus of information technology departments in most large companies and organizations. Millions of lines of programming code were reviewed and fixed during this period. Many corporations replaced major software systems with completely new ones that did not have the date processing problems.
It was the media hype story of all of 1999, but when January 1, 2000 finally came, there were hardly any major problems though a large number of them had been expected. Ironically, many people were upset that there appeared to be so much hype over nothing, because the vast majority of problems had been fixed correctly. Some more sophisticated critics have suggested that much preventative effort was unnecessary - it would have been cheaper not to spend as much examining non-critical systems for flaws and simply fix the few that would failed after the event. Such conclusions are easy to draw with the benefit of hindsight, but in any case the overhaul of many systems involved replacement with new, improved functionality anyway and thus in many cases the expenditure proved useful regardless.
Some items of interest:
![[Home]](wikipedia.png)