comp.lang.ada
 help / color / mirror / Atom feed
From: John.Devitofranceschi@U.SEI.CMU.EDU
Subject: Re: Package CALENDAR and time zones
Date: Mon, 30-Jun-86 12:52:07 EDT	[thread overview]
Date: Mon Jun 30 12:52:07 1986
Message-ID: <8606301652.AA01707@u.sei.cmu.edu> (raw)


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

             reply	other threads:[~1986-06-30 16:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1986-06-30 16:52 John.Devitofranceschi [this message]
  -- strict thread matches above, loose matches on Subject: below --
1986-06-26 21:26 package CALENDAR and time zones Stefan.Landherr
1986-06-25 20:22 Cleaveland
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox