Cleaveland@DCA-EMS (06/25/86)
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
Stefan.Landherr@SEI.CMU.EDU (06/27/86)
Reference: R.G. Cleaveland @DCA-EMS 25-Jun-86 17:28(?)
---------
I agree that the CALENDAR package is deficient in not catering for world
time zones.
However most users are interested in local time only, so any extension of
CALENDAR and any interim solution should be transparent to such users.
In addition, a calendar package with time zones should :
(1) be useful all over the world (no parochialism),
(2) cater for those places on half-hour time zones (eg South Australia),
(3) have access to the current local time zone,
(5) allow an (alterable) default zone for interpretation of times,
(4) allow conversions between time zones, and
(5) allow arithmetic and comparisons between times in different zones.
To actually designate the time zones, I recommend the usual system of letters:
Z for GMT
A, B, C, D, E, F, G, H, I, K, L, M for hours ahead of GMT
N, O, P, Q, R, S, T, U, V, W, X, Y for hours behind GMT
two-letter combinations (eg IK) for half-hour zones
------------------------------------------------------------------------------
My suggestion for the long-term solution (i.e. for Ada 88) is:
------------------------------------------------------------------------------
package CALENDAR is
type TIME is private; -- includes the time zone
subtype YEAR_NUMBER is .....
... -- unchanged
subtype DAY_DURATION is ....
type TIME_ZONE is (Y,YX,X,XW,W, .. ,N,NZ,Z,ZA,A,AB, .. ,L,LM,M);
-- half hour time zones forward from International Dateline
function LOCAL_TIME_ZONE return TIME_ZONE; -- from operating system
DEFAULT_ZONE : TIME_ZONE := LOCAL_TIME_ZONE;
function CLOCK return TIME;
function YEAR (DATE : TIME;
ZONE : TIME_ZONE := DEFAULT_ZONE) return YEAR_NUMBER;
function MONTH ... return MONTH_NUMBER; --
function DAY ... return DAY_NUMBER; -- like YEAR
function SECONDS ... return DAY_DURATION; --
procedure SPLIT (DATE : in TIME;
YEAR ...
MONTH ...
DAY ...
SECONDS ...
ZONE : in TIME_ZONE := DEFAULT_ZONE)
function TIME_OF (YEAR ...
MONTH ...
DAY ...
SECONDS ...
ZONE : in TIME_ZONE := DEFAULT_ZONE) return TIME;
function "+" ...
... -- unchanged
function ">=" ...
TIME_ERROR ... -- unchanged
private
-- implementation dependent
end CALENDAR;
------------------------------------------------------------------------------
In theory, implementations would be free to use any time zone for the internal
representation of TIME values, and the time zone returned by function CLOCK
is immaterial, provided that the TIME value is in fact the correct world-time.
However, for portability, all Ada TIME values are best stored in GMT.
Access to LOCAL_TIME_ZONE is required for portability of programs that
input or output years, months, days etc.
Conversion between time zones is through the ZONE parameter. A function to
extract the time zone of a TIME value is not needed, (and could be abused).
If DEFAULT_ZONE is left unchanged, then the use of time zones is quite
transparent to "local-time-only" users.
------------------------------------------------------------------------------
For convenience, parochial acronyms for civil time zones can be introduced by
additional, normal packages: eg
with CALENDAR; use CALENDAR;
package USA_TIME_ZONES is
type USA_TIME_ZONE is (PST, PDT, MST, MDT, CST, CDT, EST, EDT);
-- order not significant
type CIVIL_TIME_MODE is (STANDARD, DAYLIGHT);
function USA_TIME_ZONE (WORLD_ZONE : TIME_ZONE
MODE : CIVIL_TIME_MODE ) return USA_TIME_ZONE;
function PST return TIME_ZONE; -- returns U
function PDT return TIME_ZONE; -- returns T
function MST return TIME_ZONE; -- returns T
function MDT return TIME_ZONE; -- returns S
function CST return TIME_ZONE; -- returns S
function CDT return TIME_ZONE; -- returns R
function EST return TIME_ZONE; -- returns R
function EDT return TIME_ZONE; -- returns Q
ERROR : exception; -- raised by USA_TIME_ZONE for illegal inputs
end USA_TIME_ZONES;
------------------------------------------------------------------------------
As an interim solution, I suggest that the enhanced CALENDAR package
be provided as an additional pre-defined package under a different name
(eg WORLD_CALENDAR) for use by those who need it.
------------------------------------------------------------------------------
It could be argued that package CALENDAR is also deficient in not providing
facilities for:
(1) time of day (both 12 hour and 24-hour clock)
(2) names of months (abbreviated and in full)
(3) names of days of week (abbreviated and in full)
(4) correct day of week for any given date
etc
However none of these require unusual interaction with the operating system,
and thus need not be part of a predefined package, but can be provided
as normal packages.
Stefan F. LandherrJohn.Devitofranceschi@U.SEI.CMU.EDU (06/30/86)
I'm posting this for Stefan Landherr (sfl@sei.cmu.edu):
Reference: R.G. Cleaveland @DCA-EMS 25-Jun-86 17:28(?)
---------
I agree that the CALENDAR package is deficient in not catering for world
time zones.
However most users are interested in local time only, so any extension of
CALENDAR and any interim solution should be transparent to such users.
In addition, a calendar package with time zones should :
(1) be useful all over the world (no parochialism),
(2) cater for those places on half-hour time zones (eg South Australia),
(3) have access to the current local time zone,
(5) allow an (alterable) default zone for interpretation of times,
(4) allow conversions between time zones, and
(5) allow arithmetic and comparisons between times in different zones.
To actually designate the time zones, I recommend the usual system of letters:
Z for GMT
A, B, C, D, E, F, G, H, I, K, L, M for hours ahead of GMT
N, O, P, Q, R, S, T, U, V, W, X, Y for hours behind GMT
two-letter combinations (eg IK) for half-hour zones
------------------------------------------------------------------------------
My suggestion for the long-term solution (i.e. for Ada 88) is:
------------------------------------------------------------------------------
package CALENDAR is
type TIME is private; -- includes the time zone
subtype YEAR_NUMBER is .....
... -- unchanged
subtype DAY_DURATION is ....
type TIME_ZONE is (Y,YX,X,XW,W, .. ,N,NZ,Z,ZA,A,AB, .. ,L,LM,M);
-- half hour time zones forward from International Dateline
function LOCAL_TIME_ZONE return TIME_ZONE; -- from operating system
DEFAULT_ZONE : TIME_ZONE := LOCAL_TIME_ZONE;
function CLOCK return TIME;
function YEAR (DATE : TIME;
ZONE : TIME_ZONE := DEFAULT_ZONE) return YEAR_NUMBER;
function MONTH ... return MONTH_NUMBER; --
function DAY ... return DAY_NUMBER; -- like YEAR
function SECONDS ... return DAY_DURATION; --
procedure SPLIT (DATE : in TIME;
YEAR ...
MONTH ...
DAY ...
SECONDS ...
ZONE : in TIME_ZONE := DEFAULT_ZONE)
function TIME_OF (YEAR ...
MONTH ...
DAY ...
SECONDS ...
ZONE : in TIME_ZONE := DEFAULT_ZONE) return TIME;
function "+" ...
... -- unchanged
function ">=" ...
TIME_ERROR ... -- unchanged
private
-- implementation dependent
end CALENDAR;
------------------------------------------------------------------------------
In theory, implementations would be free to use any time zone for the internal
representation of TIME values, and the time zone returned by function CLOCK
is immaterial, provided that the TIME value is in fact the correct world-time.
However, for portability, all Ada TIME values are best stored in GMT.
Access to LOCAL_TIME_ZONE is required for portability of programs that
input or output years, months, days etc.
Conversion between time zones is through the ZONE parameter. A function to
extract the time zone of a TIME value is not needed, (and could be abused).
If DEFAULT_ZONE is left unchanged, then the use of time zones is quite
transparent to "local-time-only" users.
------------------------------------------------------------------------------
For convenience, parochial acronyms for civil time zones can be introduced by
additional, normal packages: eg
with CALENDAR; use CALENDAR;
package USA_TIME_ZONES is
type USA_TIME_ZONE is (PST, PDT, MST, MDT, CST, CDT, EST, EDT);
-- order not significant
type CIVIL_TIME_MODE is (STANDARD, DAYLIGHT);
function USA_TIME_ZONE (WORLD_ZONE : TIME_ZONE
MODE : CIVIL_TIME_MODE ) return USA_TIME_ZONE;
function PST return TIME_ZONE; -- returns U
function PDT return TIME_ZONE; -- returns T
function MST return TIME_ZONE; -- returns T
function MDT return TIME_ZONE; -- returns S
function CST return TIME_ZONE; -- returns S
function CDT return TIME_ZONE; -- returns R
function EST return TIME_ZONE; -- returns R
function EDT return TIME_ZONE; -- returns Q
ERROR : exception; -- raised by USA_TIME_ZONE for illegal inputs
end USA_TIME_ZONES;
------------------------------------------------------------------------------
As an interim solution, I suggest that the enhanced CALENDAR package
be provided as an additional pre-defined package under a different name
(eg WORLD_CALENDAR) for use by those who need it.
------------------------------------------------------------------------------
It could be argued that package CALENDAR is also deficient in not providing
facilities for:
(1) time of day (both 12 hour and 24-hour clock)
(2) names of months (abbreviated and in full)
(3) names of days of week (abbreviated and in full)
(4) correct day of week for any given date
etc
However none of these require unusual interaction with the operating system,
and thus need not be part of a predefined package, but can be provided
as normal packages.
Stefan F. Landherr