Term of the Moment
application sharing
Redirected from: 2000 time problem
Definition: Y2K problem
(Year 2000 problem) The inability of older hardware and software to recognize the date after the year 2000. The reason they could not was because the year was stored with only two digits in many databases; for example, 12-11-03 instead of 12-11-1903. Therefore, after the turn of the century, was this date 1903 or 2003? Every program that dealt with dates could have problems.
Dates Are Critical
Financial transactions often match dates in database records with today's date or with a future date. If the system does not handle dates correctly, bills do not get paid, notices do not get triggered and actions are not taken. After 2000, any system that could not recognize the change would cause erroneous output with applications that dealt with future dates. Although warnings of disaster prevailed, there were only a few incidents when all was said and done.
Fixing It Was a Massive Job
The solution to this "millennium bug" required upgrading hardware to support four-digit years, converting files and databases to four-digit years and converting all the software that referenced dates. Enterprises had a huge amount of legacy data files and thousands of programs that accessed them. With many older applications, the programmers who wrote them were long gone, and documentation was lacking. In many instances, the source code was missing. Even when changes could be made, the time it took to test them was taxing on the IT staff. See Y2K anxiety.
Just to Save Two Bytes!
The problem originated with punch cards that go back to the early 1900s. In order to cram an entire order or customer record into a single punch card with 80 or 90 character columns, the year was shortened to two digits. Why waste two columns for "19" when it was going to be "19" for a very long time. When punch card systems were converted to magnetic tape in the 1960s, and there was ample room to convert to four digits, laziness prevailed because 2000 still seemed very distant. Saving two columns (two bytes) in a punch card was appropriate, but not when there was ample storage on tape.
Problems Occurred Even Before 2000
For example, imagine a company wanting to delete customers who had not purchased anything in the previous five years. The program logic would add 5 to the year of the last order and compare the result with the current year. Suppose a customer last ordered in 1995 and the current year were 1996. Add 5 to 95 in a non-Y2K compliant system and the result was 00, not 2000. Since 96 was greater than 00, the customer record would be deleted. See data aging.
Another Date Problem 38 Years Later
Because of the way dates are stored in Unix systems, the year 2038 presents another challenge (see Year 2038 problem).
The Y2K Problem
About Time
Making a Strong Point
Perhaps Overly Dramatic
Even Before Y2K
Dates Are Critical
Financial transactions often match dates in database records with today's date or with a future date. If the system does not handle dates correctly, bills do not get paid, notices do not get triggered and actions are not taken. After 2000, any system that could not recognize the change would cause erroneous output with applications that dealt with future dates. Although warnings of disaster prevailed, there were only a few incidents when all was said and done.
Fixing It Was a Massive Job
The solution to this "millennium bug" required upgrading hardware to support four-digit years, converting files and databases to four-digit years and converting all the software that referenced dates. Enterprises had a huge amount of legacy data files and thousands of programs that accessed them. With many older applications, the programmers who wrote them were long gone, and documentation was lacking. In many instances, the source code was missing. Even when changes could be made, the time it took to test them was taxing on the IT staff. See Y2K anxiety.
The problem originated with punch cards that go back to the early 1900s. In order to cram an entire order or customer record into a single punch card with 80 or 90 character columns, the year was shortened to two digits. Why waste two columns for "19" when it was going to be "19" for a very long time. When punch card systems were converted to magnetic tape in the 1960s, and there was ample room to convert to four digits, laziness prevailed because 2000 still seemed very distant. Saving two columns (two bytes) in a punch card was appropriate, but not when there was ample storage on tape.
Problems Occurred Even Before 2000
For example, imagine a company wanting to delete customers who had not purchased anything in the previous five years. The program logic would add 5 to the year of the last order and compare the result with the current year. Suppose a customer last ordered in 1995 and the current year were 1996. Add 5 to 95 in a non-Y2K compliant system and the result was 00, not 2000. Since 96 was greater than 00, the customer record would be deleted. See data aging.
Another Date Problem 38 Years Later
Because of the way dates are stored in Unix systems, the year 2038 presents another challenge (see Year 2038 problem).
When data were copied from punch cards to magnetic tape records starting in the 1960s, the two-digit year was generally copied verbatim because the next century seemed very distant. See 3 C's.
This conference was from the Software Productivity Group, an organization that provided the necessary training to deal with this sticky subject. (Image courtesy of Software Productivity Group)
Year 2000 compliance software from Isogon was used to test IBM mainframe applications running the MVS operating system. (Image courtesy of Isogon Corporation.)
There was a lot of concern before the millennium that things could get out of hand. However, had the world not spent hundreds of billions of dollars revamping thousands of applications, there would have been many problems. There were only a few.
Program maintenance is always a problem in this industry. This commentary from PROCASE Corporation was created more than a decade before Y2K. PROCASE provided software that could flow chart a program from its source code in order to make it understandable.