Re: Limits on type Duration and package Calendar

[rlk@telesoft.com (Bob Kitzberger @sation)]

In article <57925@bbn.BBN.COM>, mbrinn@bbn.com (Marshall Brinn) writes:
>
> In the LRM, it defines that type DURATION need only ranuge up to 84600.0,
> ie., the number of seconds in a day (the definition of CALENDAR.DAY_DURATION).
> 
> However, package CALENDAR provides functions "+" and "-" where the difference
> between two times is given as a DURATION. How then does this package handle
> the difference between two days that are more that one day apart? Some 
> compilers I've tried seem to have a reasonably high value for DURATION'last,
> at least one (TELESOFT TELEGEN2 1.4) used the one-day upper bound.

Since Duration is a fixed-point type, there is a trade-off between high
resolution and a "reasonably high value" -- i.e. high upper bound.  Using a
_minimal_ number of bits to represent the integer portion of Duration (e.g.
17 bits and 1 sign bit) allows a _maximal_ number of bits to represent the
fractional portion, a desirable approach for embedded systems in which accurate
time measurements are important.  For a 32-bit representation of Duration,
this leaves 14 bits to represent the fractional portion, for a resolution 
of about 61 microseconds.

It may be argued that non-embedded systems should have a larger number of 
bits for the integer portion of type Duration, though this begs the question
of how many is enough to represent a "reasonably high value"?  

I know this doesn't answer your question... but maybe it sheds some light on
the trade-offs compiler vendors have to make in implementing Ada's time
abstraction.  Things get much more complicated when you throw in 
System.Tick (which is relatively useless and hard to implement meaningfully), 
network time syhchronization, and low-level hardware timers whose values
don't map exactly onto a binary fraction.

IMHO, Calendar is trying to handle the time abstraction for two different
problem domains that are better left separate -- 1) time-of-day calculations,
and 2) real time measurements.  Type Duration is the "bridge" between the
two abstractions.  Sigh.

It looks to me like you'll need to "roll your own" solution, with calls to
Calendar.Split to get the yr/mon/day/sec fields of both timne operands.

	Bob Kitzberger
	Software Engineer, Ada Tasking

-- 
Bob Kitzberger               Internet : rlk@telesoft.com
TeleSoft                     uucp     : ...!ucsd.ucsd.edu!telesoft!rlk
5959 Cornerstone Court West
San Diego, CA   92121-9891   "There's too much caffeine in your bloodstream..."
(619) 457-2700 x163                                              -- The Smiths
------------------------------------------------------------------------------