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: Charles Hixson Subject: Re: Ada Calendar oddity Date: 2000/05/11 Message-ID: <391ADDEA.E715259@earthlink.net>#1/1 X-Deja-AN: 622165754 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> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.prod.itd.earthlink.net 958062063 198.94.156.19 (Thu, 11 May 2000 09:21:03 PDT) Organization: EarthLink Inc. -- http://www.EarthLink.net MIME-Version: 1.0 NNTP-Posting-Date: Thu, 11 May 2000 09:21:03 PDT Newsgroups: comp.lang.ada Date: 2000-05-11T00:00:00+00:00 List-Id: 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).