saharbaugh%roo.dnet@WINNIE.FIT.EDU (07/06/90)
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
---------------------eachus@linus.mitre.org (Robert I. Eachus) (07/06/90)
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...