package CALENDAR and time zones.

[Cleaveland@DCA-EMS]

I note that the package CALENDAR is not specified to represent time
in any particular world time zone.  Implementations historically have
reflected the year, day, hour, minute and second returned by the
underlying operating system clock.  While the operating systems
usually also report time zone information, this aspect is ignored in
presenting the data to an Ada application through the subprogram
CALENDAR.CLOCK.  

There are a great number of applications which require the collation
and comparison of time data of varying time zones, and a need to
present time information to users in terms they can most easily
relate to - that is, "local" time.  The application I had that brings
this to mind is the sorting of net messages received by time of
origination, where the messages were originated on many different
hosts at different time zones.


It seems to me that there are two approaches to effecting a fix.  One
is to add an element for time zone to the type TIME, and the other is
to "clarify" the specification of TIME semantically to mean GMT, and
then do zone adjustments on input/output.

  a. To add an element "zone" to "time" while preserving
  compatability with the current definitions would require additional
  parameters in SPLIT and TIME_OF as well as an additional subtype
  for zone and a new function to extract that parameter similar to
  the function YEAR.  Programs prepared on the basis of the current
  specification would likely require modification to accomodate the
  extra parameter in SPLIT and TIME_OF when the new package was
  introduced.  The only way around this is to have the enhancement
  reflected not in CALENDAR but in a required replacement with a
  different name (WORLD_CALENDAR?).
  
  b.  If a clarification were issued such that "TIME" was understood
  to be in terms of GMT, then it would generally be up to the vendors
  of CALENDAR bodies to effect the standard in the implementation of
  the function CLOCK.  They would do this by looking at the operating
  system to get zone information and then adjust the time from the
  clock to create GMT.  In most cases, until that change were effected
  application programs would receive operating system time, usually
  (but not exclusively) "local".  Some hosts' clocks are set to GMT.
  In some cases applications would require revision to accomodate the
  change; the program that had been printing out "this message received
  at .... EDT" because it (necessarily) made an assumption about zone
  would have to change, either by indicating the zone as GMT or
  converting to EDT.
  
AN alternative of preparing a super-package above CALENDAR which
would accomodate time zone information was not explored on the
principle that CLOCK hides any time zone information available from
its source, and the super-package CLOCK would have to "go around"
CALENDAR.CLOCK to get the information from (probably) that same
source.  Hence the super-package would necessarily constitute a
replacement for that one function at least.

I recommend alternative (b).  In many cases the implementation could
be effected by directing the hosts system clock be set to GMT, and
making a minor change or two to the (not standardized) application
programs which input/output time.  I would be interested in other's
views on the subject.

R.G. CLEAVELAND