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

[Charles Hixson <charleshixsn@earthlink.net>]

Thanks for the reply.  Some responses follow (interspersed as appropriate).
Geoff Bull wrote:

> Charles Hixson wrote:
> >
> > It seems to me that it is a mistake to include seconds, much less any smaller
> > unit, in the calendar date.
>
> Astronomers and real time programers, e.g., might not agree
> with you. Although, of course, the latter group are catered
> for with Ada.Real_Time.
>
> >  I'm not sure that minutes is justified, but if
>
> Depends on what requirement you are trying to meet.

I was assuming a split between the Calendar class and the Time class.  Clearly if
one is building a DateTime class then minutes *MUST* be included.

> > one uses a 64 bit number then it wouldn't seem to cause any problems.
>
> Elsewhere it has already been stated that no more than 32 bits
> is essential (I have no opinion on this0.

But the 64 bit chips are starting to become more common.  How many bits is
essential depends on what one is trying to do (and the degree of precision).  By
some measures all that one needs is the floating point (32 bit!) # of years since,
say the founding of the city of Rome (i.e., A.U.C. dating).  But many wouldn't find
that convenient.  (And date/time formatting from that to the current calendar would
be a real nuisance!)

> > 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.
>
> This is perhaps not a bad idea, because seconds and days are
> different concepts, one being a fixed period of time, the other
> being the variable amount of time for one rotation of the earth
> (either wrt to the sun or the stars).

I was thinking of days as being solar, and of seconds as being determined by atomic
clocks, but this probably doesn't signify.

> >  Or time could be defined with the top 32 bits being ...
>
> Of course it would be defined as a private type.

Well, yes.  But the implementor would need to be able to share information between
the Date and Time packages.  Of course, I may be making things more complex than
necessary.  I don't know how many bits of precision a 64 bit float would have, but
suppose one measured the number of days since 01/01/1904 (in honor of the Macintosh
[I think that's the right date!]).  To what precision could 12:01:03.14159 of
3000/01/31 be represented?  Of course, if this course is chosen, then one will need
to figure out what to do when a "leap second" is announced.  I was trying to skip
out of that problem.  Otherwise a sufficiently precise floating point number would
do all that one needed  (except for nicely formatted I/O).

The remaining problem would be how to specify the degree of accuracy to which the
time was known.  Consider "early in the morning of July 30 this year" or "sometime
in the late summer, of 4 BC" or "around 200,000 years ago".  These are all times,
specified to varying degrees of accuracy.

A slightly different kind of problem is "early in the spring, about a decade ago"
where the time of year is specified vaguely, but which year, itself, is not
specified.  This probably won't be handleable by any reasonable time class, but
needs consideration (as a representative of a class of problems).