Even in open architecture systems, such as VME, where integrators use standard modules, each component will have been supplied with its own driver and bindings all potential date problems.
Users must go through the process of checking all code line-by-line, because of hidden occurrences of a date being called from the OS and embedded in data file names and strings.
All real time clocks have a base date of 1900; when called, the current date is returned as the years on ie +99 or +100. But in elderly software, week 99, year 99 was often used to indicate either an indeterminate date, or a default to terminate the subroutine.
So, the date problem could manifest itself on 1st January 1999 or, with programs that look ahead, sometime in 1998!
The problem, when returning a value of 100 for the year 2000, is how the application treats it. It may default to error or, depending on whether the most or least significant digit is discarded, the resulting value will be 10 or 00.
At the trivial level, an incorrect screen display is just annoying; but if an incorrect date field is used in sorting, comparing or computation, the results can be a complete crash, incorrect operation or data corruption over time.
To solve the problem is far more work than most realise. Most upgrades, patches and fixes will be undocumented, even if the original source code is available. Also, many applications will be in old, now unsupported languages how can they be fixed? Testing is another huge issue; most automated test and simulation routines are not set up to look for errors in date fields, but concentrate on process variables.
Our concern, as a supplier, is that many users believe that it’s a vendor problem. It clearly is not; and unlike some deadlines, the year 2000 cannot be moved.
Take action now!.