Package Calendar

Package Calendar

[saharbaugh%roo.dnet]

Here are a few other things to consider about package Calendar:
1. There are two values for midnight (0.0 & 86400.0) like
   a magnetic compass which has two values for north ( 0.0 & 360.0) but
   unlike my wall clock where straight up is 12:00 not 0:00.
2. There is no provision in package Calendar for indicating
   that the reported value is suspect.  My >50 year old mantle
clock has a flag that drops when the power fails to indicate
that you should suspecct what the face is saying( good
thing my face has no such flag). My digital clocks flash when
power failure destroys their credibility.  
3.  There is no provision for setting the clock or handling
    leap seconds, when the committee in France adds a second to
    adjust for slowing of the earth's rotational rate.
-
   People tell me I am nitpicking to which I say "Oh!, If you
don't really want to know what time it is then use
package Calendar, it is useful for short duration
benchmarks etc. BUT if you are building a real-time control
system then (as the posting said)roll-your-own",  I see
advertized boards for the PC which decode WWVB time
signals. I believe you must turn to an integrated hardware/software
solution for serious timekeeping.
regards, sam harbaugh
---------------------

Re: Package Calendar

[Robert I. Eachus]

In article <9007051846.AA01362@winnie.fit.edu> saharbaugh%roo.dnet@WINNIE.FIT.EDU writes:

>   1. There are two values for midnight (0.0 & 86400.0) like
>   a magnetic compass which has two values for north ( 0.0 & 360.0) but
>     unlike my wall clock where straight up is 12:00 not 0:00.

    If you read AI-196 you will find that TIME_OF and SECONDS never
return 86400.0, but that TIME_OF can be called with a value of
86400.0.  A useful idiom for geting tommorow's date is:

   declare
     use CALENDAR;
     TODAY: TIME := CLOCK;
     Y: YEAR_NUMBER;
     M: MONTH_NUMBER;
     D: DAY_NUMBER;
   begin
     SPLIT(TIME_OF(YEAR(TODAY),MONTH(TODAY),DAY(TODAY),86400.0),Y,M,D);
     ...
   end;

>  2. There is no provision in package Calendar for indicating
>     that the reported value is suspect.  My >50 year old mantle
>  clock has a flag that drops when the power fails to indicate
>  that you should suspecct what the face is saying( good
>  thing my face has no such flag). My digital clocks flash when
>  power failure destroys their credibility.  

     It is certainly legal for CLOCK to return a value which raises
TIME_ERROR when passed to SPLIT, or for the returned value to raise an
immediate CONSTRAINT_ERROR.  Is there a need for uniformity in this
area? or should we continue to allow implemtnation freedom. Currently
a program which calls CLOCK and uses the value obtained is erroneous
if the clock was never set.  Note that the act of calling CLOCK does
not necessarily make the program erroneous.

>  3.  There is no provision for setting the clock or handling
>      leap seconds, when the committee in France adds a second to
>      adjust for slowing of the earth's rotational rate.

     I would hate to see the idiom above fail because of leap seconds,
but otherwise, I think it is a good idea to separate the user view of
time from the view required by a system manager.  A good
implementation of CALENDAR on an embedded system might also provide a
package SYSTEM_TIME for setting clocks etc. However, such a package
would obviously be system dependent.

     The abstractions that I think are missing from package CALENDAR
are time zone operations, and the ability to get the number of days
between two dates.  I hope these will be added in Ada 9X.
--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...