Re: Ada Calendar oddity <was Re: C date package>

[Charles Hixson <charleshixsn@earthlink.net>]

Preben Randhol wrote:

> -- snip
> >If I were designing such a package, I would think about the number of
> >bits needed to represent the number of seconds (or nanoseconds?) in the
> >range.
>
> I think that in this case one needs to use another type for the birth
> and expiration date and convert from Ada.Calendar the date of today if one
> also wants the date when the license was issued.
>
> --
> Preben Randhol -- [randhol@pvv.org] -- <http://www.pvv.org/~randhol/>
>          "Det eneste trygge stedet i verden er inne i en fortelling."
>                                                       -- Athol Fugard

It seems to me that it is a mistake to include seconds, much less any smaller
unit, in the calendar date.  I'm not sure that minutes is justified, but if
one uses a 64 bit number then it wouldn't seem to cause any problems.
(Calendar corrections for seconds are SO much more common than corrections for
minutes!)  2^63 minutes would seem to express any particular time that one
would want to talk about.
Perhaps Calendar and Time could be two separate packages, each using a 64-bit
number as their base, one based on days and the other based on
?nano?-seconds.  Or time could be defined with the top 32 bits being
equivalent to the bottom 32 bits of Calendar, and the "lower" 32 bits being a
floating point number guaranteed to be less than 1, a fractional number of
minutes.  This would allow DateTime to be a 96 bit number good for (nearly)
everything.  This would make formatting the I/O a bit of work, but would make
date and time calculations very simple.  It seems to me that one would gain on
one would more than make up for what one would loose on the other (I calculate
with Time-s a lot more than I display them).