What do we mean by "The Year 2000 Problem"? THE JOKE
Many computer programs and data bases have been designed in such a way that years, as part of a date or as part of another field (e.g fiscal periods) are represented by 2 digits. For example 23rd January 1993 might be stored as 23-01-93 or 230193. Or the first period in fiscal year 1997 is represented as 97-01.
Until recently data stored in this fashion has been reliable because it could be safely assumed that all dates fell within the 1900s. As from 1st January 2000 that assumption will no longer be valid - 230193 could represent 23rd January 1993 or 23rd January 2023 - and many computer systems will cease to function reliably from that date onwards.
Many computer applications that must calculate a date in the future are already producing erroneous results.
How did this situation arise?
The aforementioned storage scheme was employed and became the de facto standard several years ago. At the time it was considered an efficient way of storing data because it minimised then expensive disk and memory computer resources.
Nowadays computers are more powerful and have far more memory and storage, and modern software and database management systems can store dates in more efficient formats without the need to shorten the year portion of the date; but it is still a common practice to capture dates in a shortened format: partly because it has become accepted as a standard, and partly because it reduces the number of keystrokes at capture time. In such cases the software must place the date it is presented with in a fixed, arbitrary 100 year range. The decision making process will vary from product to product, but in many cases it will be presumed that the date falls within the 1900s.
Other issues compounding the problem are:
  • Failure of systems to recognise 2000 as a leap year
  • Use of historic data generated by old systems written many years ago.
Why is this a serious problem?
At first glance an ambiguity in date data can seem fairly trivial. In reality it is potentially disastrous. Consider some of the possible consequences:
  • Forward calculated dates will be ambiguous. This is already becoming a problem in that computerised inventory systems are calculating that newly manufactured goods are already past their sell-by date and flagging these goods (perishables, tinned goods and medicines) for removal from inventory. In the next century this problem will become more severe: Goods that are too old could be left on the shelves because computer systems will calculate that the goods are still fresh.
  • Transactions that take place towards the end of 1999 may be entered into ledgers as having taken place in the year 2099.
  • Calculations of dividends or interest, based on the calculated age of an investment or debt will be wildly inaccurate.
  • Calculated ages of customers will be incorrect.
  • Errors in payroll systems could provoke industrial action.
  • Planned production systems may calculate lead times, deadlines and production requirements incorrectly.
  • 29th February 2000 will be a Tuesday. If your systems won't recognise 2000 as a leap year then you may not be able to do business on that day.
Take a few minutes and you'll come up with more possible scenarios.
Case studies conducted in the USA and in Europe suggest that this problem is very serious, and that many companies are going to find it difficult and perhaps impossible to do "business as usual" after 31st December 1999.
In fact some companies are already running into problems because of this bug. For example some supermarket chains in the USA have found that their tills will not accept credit cards that expire on dates later than 31-12-1999.
Rá and the Year 2000
At Rá we have taken pains to ensure that our systems will handle the change of millenium without skipping a beat - and we continue to take such pains as we develop and enhance applications.
UniVerse, our preferred DBMS, handles the change of millenium flawlessly. One of our programmers recently tested UniVerse's date handling: He got to the year 6651 and the system was still handling the dates perfectly.
| More about us | Our products | Contact Us | Links | 2000 | Webs | Home |