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

[Geoff Bull <gbull@acenet.com.au>]

Charles Hixson wrote:
> But the 64 bit chips are starting to become more common.

You would probably want to have Extended_Calendar in an optional
annex, e.g. information systems. 
The RM only requires 16 bit ints, 24 bit fixed and single
precision floats (32 bit). I can't see people being too enthused
about forcing these limits up to 64 bit just to make date/time
more useful.

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

Atomic clocks are convenient because you can get TAI and UTC 
(they differ only by leap seconds) from GPS (including leap
second broadcasts). It is reasonable to assume that 
*most* implementations can relate local time to UTC
by a time zone offset.

> I don't know how many bits of precision a 64 bit float would have, 

3.5.7 (15) If Long_Float is predefined for an implementation, then
           its requested decimal precision shall be at least 11. 

> suppose one measured the number of days since 01/01/1904 (in honor of the Macintosh
> [I think that's the right date!]).

Why can't we just use the epoch for TAI?


> 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. 

I saw a name for this time system somewhere.
The example was if you referred to the "'50s" you mean the period
1946 to 1954. The name of this system escapes me, but it is
a sufficiently fuzzy concept to be of no use for defining a
Calendar package.