Volume 4, number 5, December 1996, pages 32-33

Windills
Beyond the year 2000, there be dragons...

by Ed J.P.M. de Moel

We all have seen numerous articles in the press lately, both in the general press and in the M[UMPS] related literature, that deal with the possible problems that may or will arise once we have celebrated the first new year's eve that enters us into a year that no longer has "19" as its first two digits.

Some problems have already happened: I recently overheard the people at a car rental agency instructing a new clerk to enter expiration dates on drivers licences that are in the years 2000 or 2001 as "99", because otherwise, the computer would think that the license in question expired over 90 years ago, and the machine would refuse to rent a car to the owner of the fairly recently renewed driver's license.

In a previous column, I already indicated that $HOROLOG offers us a tool that could help us to deal with dates in a manner that does not suffer from "turn-of-the-century" problems. But is such a tool really the answer to all the possible problems?

In comp.lang.mumps, there have been several exposés of the usage of several tools, both standardized tools and implementation specific ones, that sometimes help indeed to avoid problems, and sometimes turn themselves against us.

In this column, I would like to repeat some "do's and don'ts" and emphasize a couple of areas where some additional care and review might be in place.

How should we store dates?

There are several good answers to this question. Basically, any format that preserves enough information to know which century a date is in is a good one. Examples are:

And many, many more.

Some of these formats have the advantage that they collate in the same order as the dates that they represent, some do not preserve the collating order. E.g. "2000-Jan-31" would sort after "2000-Feb-1", but, "2000-01-31" will always precede "2000-02-01", and this collating sequence will also be maintained when a different separator character is chosen.

A nice additional feature of the forms that offer some redundancy is that they can be used to store "imprecise" dates. "2000-02-00" and "3000200" could be used to indicate that we know that a date is in February of the year 2000, but we don't know (or care) exactly on which day, whereas a format like the Julian date or $HOROLOG would not allow for any "imprecise" date between the end of one month and the start of the next. In fact, some of the utilities that do conversions between $HOROLOG format and "readable" form can be tricked into converting "0-FEB-2000" into 58104, and when we convert that number back to "readable" we end up with "31-Jan-2000"... (Of course, the "better" conversion utilities would report an error when the day-number is less than 1 or higher than the last day of the month in question.)

How should we display dates?

There is no answer to this question that will always be seen as "correct". In practice, the answer to this question will be dictated by a number of considerations that are dependent on the situation at hand:

How does one enter a date?

Of all the questions I wanted to address in this issue, this one is the hardest to answer: the answer to this question cannot be dictated by a programmer or by a standards committee, this answer will come from the end user.

If we write software that neatly prevents all possible problems, but forces the end user to enter information in a form that he or she is not willing to use, it is quite predictable that that end user will be looking for a different software provider.

So... our software should be kind to the people who enter the data, and should make reasonable attempts to figure out what they mean.

Now, where does "my" software make any wrong assumptions...


Ed de Moel is past chairman of the MDC and works with Jacquard Systems Research. His experience includes developing software for research in medicine and physics. Over the past ten years, Ed's has mostly focused on the production of tools for data management and analysis, and tools for the support of day-to-day operation of medical systems. Ed can be reached by e-mail.