ills
illsM Computing, Volume 3, number 3, June 1995, pages 60-61
The year 2000 is coming. All around us there are panicky voices: will our software be able to know what the meaning of 29-FEB-00 is? Will our automated procedures start sending messages to the parents of our very senior citizens, enticing them to buy the kind of toys and educational materials that are so useful for tots and pre-schoolers?
The answer, of course, is that it depends.
There are many ways of storing information about dates and events in computers. In M[UMPS], there are several popular ways:
If software uses $H[OROLOG] for the internal representation of dates, there is a slight penalty for the conversion when data is entered or presented, but it is extremely easy to compute the difference between two internal dates as a number of days, and from there, and conversions to months and years are not too hard either.
If software uses FileMan format for the internal representation, the conversion from external representation to internal representation is fairly straightforward, and there is a slight conversion penalty when a difference between two dates needs to be computed. One additional feature that comes with the FileMan date-format is the option to store imprecise dates.
If software uses human-readable text strings, however, there may be some problems. There are many forms that each are perfectly usable as a date format, but some are more resilient than others. First, there is the order of the parts: 7/8/90 stands for the 7th of August of 1990 in Europe, while it represents the 8th of July in the USA. As long as the usage of software stays within national boundaries, there is no problem concerning this difference in interpretation, but as soon as software starts to be used internationally, it becomes important that a format is chosen that is unambiguous to all users (the project that I work on uses FileMan format internally, and for external representation always writes the month as a three character abbreviation, so that it is clear which part of a date is the day and which is the month, even if the parts don't appear in the favorite sequence from the human reader's perspective).
And there, just above, I have done it: when I wrote 7/8/90, is that 1890, 1990 or 2090? Mostly, that is an interpretation that is left to the user-friendly input modules. If we ask for a birthdate, and a user enters 8/8/99, our software automatically assumes that it must be in the past, and will find 1899 more likely than 1999; on the other hand, if the software were to ask for a date when an ongoing activity will end, a date in the future would be assumed by default...
But not all cases are so self-evident. In those cases, the standard method of performing data-entry on our project insists that we show the user what the computer assumes, and ask for a confirmation:
Please confirm: 8-AUG-1999//
and allow the user to override by entering 8-AUG-1899, for instance.
As long as, internally, the software has enough information to know which century a date is in, the software will be able to make correct decisions based on those dates, and won't try to recruit senior citizens for enrollment in the local kindergarten, even if it would display their birthday as 2-FEB-2... If the software would actually store the date like that internally, some interesting problems can be expected to start happening soon.
In M[UMPS] we have so many ways of doing it right... I can only hope that that's what we're doing.
By the time that this will be printed, a lot more will be known, but at the time I am writing this, we are just entering the re-canvass phase.
So, what is going on with the draft standards? During the second half of 1994, the MUMPS Development Committee (MDC) has circulated 5 draft standards among the canvass-lists for the various standards.
Two, the GKS draft standard and the X Window draft binding received no objections, and were forwarded to ANSI for confirmation as an ANSI standard. Both were accepted by ANSI, so, currently we have an ANSI X11.3-1994 GKS binding and an ANSI X11.4-1994 X Window binding.
That leaves three draft standards:
For all objections, we entered into a discussion by mail with the various objectors. In this way we we were able to resolve two of the objections. One objection to the language standard was a request to allow for a specific syntactic construct. The objector agreed with us that this kind of modification is best realized by sending a proposal to modify the language to the subcommittee that addresses these issues and let it work its way through the established process. The other objection that could be resolved was the one to the MWAPI. This one is not easily explained in a column like this, but the essentials of the correspondence back and forth will be published in this magazine.
So... at the moment I am writing this, I am also preparing the mail-packages for the re-canvass of the remaining two draft standards. The packages contain the texts of the remaining objections and the responses that the MDC eventually sent to the objectors. In addition, there is some information about a standards-related appeal that one of the objectors has initiated. It is now up to the members of the canvass-groups to decide whether they stick to their original vote (in favor of acceptance of the document being canvassed), or to support one or both of the objections and change their vote. By the time you will read this, the votes will be cast, and we will know whether we have a new M[UMPS] language standard and OMI standard, or not.
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.