From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!DCA-EMS!Cleaveland From: Cleaveland@DCA-EMS Newsgroups: net.lang.ada Subject: package CALENDAR and time zones. Message-ID: <8606252238.AA21586@ucbvax.Berkeley.EDU> Date: Wed, 25-Jun-86 16:22:00 EDT Article-I.D.: ucbvax.8606252238.AA21586 Posted: Wed Jun 25 16:22:00 1986 Date-Received: Sat, 28-Jun-86 03:19:22 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet List-Id: 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