From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,cfd23c10fd537a80 X-Google-Attributes: gid103376,public From: Geoff Bull Subject: Re: Ada Calendar oddity Date: 2000/05/12 Message-ID: <391B7FA7.A98E0D10@acenet.com.au>#1/1 X-Deja-AN: 622406890 Content-Transfer-Encoding: 7bit References: <39176D85.603D7AEC@research.canon.com.au> <39178DEA.FD2C20FA@research.canon.com.au> <8f92o1$6v$1@nnrp1.deja.com> <3918BB77.693C70D6@research.canon.com.au> <8fahfv$mgt$1@nnrp1.deja.com> <3919862C.7870D7D8@earthlink.net> <391AB6C4.5CEE8F@acenet.com.au> <391ADDEA.E715259@earthlink.net> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@telstra.net X-Trace: nsw.nnrp.telstra.net 958103656 203.35.118.1 (Fri, 12 May 2000 13:54:16 EST) Organization: Customer of Telstra Big Pond Direct MIME-Version: 1.0 NNTP-Posting-Date: Fri, 12 May 2000 13:54:16 EST Newsgroups: comp.lang.ada Date: 2000-05-12T00:00:00+00:00 List-Id: 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.