Re: Year 2000

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 11

As I have been working on the Year 2000 problem for the last five months I have noted Bob Brown’s letter (Vector 14.1 p. 8) and at first dismissed it, but on closer examination I thought there is a good reason to reply. If you can’t bear the suspense please skip to the last paragraph.

I am currently working for a Life Insurance/Pensions company with APL systems dating back to 1984. Most were written by actuaries, pension administrators and apprentice APL programmers. As you can imagine dates are very important and used in many calculations. You would also expect that these programs must already cope with the next century; well some do, by using a three-digit year, e.g. 101 means 2001!

If you think about it you can represent a date in at least a dozen formats and that is just the numeric ones! Consequently we have some 64 functions just converting from one representation to another and back again. We have several programs to convert to and from serial (often called Julian) dates, some include the 400 leap year rule and a couple even the 4000 year rule! None of them comes up with ‘standard’ Julian dates (1/1/1900=1), and all get the 2000 leap year wrong! Most treat AD 1900 wrongly as a leap year (as does MS Excel v.4a), although this is unlikely to cause problems by now. Then we have lots of rate tables mostly keyed on a two-digit year, all references to ⎕TS must be examined, etc.

To complicate matters The Management in their wisdom has decreed that screens, printouts and file layouts (linking to non-APL systems) are NOT to be changed. Thus we are to internally ‘window’ the dates, i.e. any year <30 is presumed to be >2000. It may sound easy, but is 12/8/38 a date of birth or a retirement date? How do the date-handling functions tell the difference?

Examining all the APL code would take 16 man-years. By eliminating all the dead systems and code and concentrating on business critical systems we can do it in 3 man-years. It is too late to re-write the systems, and they would not let us anyway.

Bob Brown is right — it should never have happened — but this is not a perfect world and we the consultants have to tediously patch things up to last another few years.

Here is the proof. If Bob Brown examines his functions he will find that they are unaware of 2000 being a leap year!!!

M.E. Martin
General Software