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/10 Message-ID: <3919862C.7870D7D8@earthlink.net>#1/1 X-Deja-AN: 621612055 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> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.prod.itd.earthlink.net 957974068 198.94.156.19 (Wed, 10 May 2000 08:54:28 PDT) Organization: EarthLink Inc. -- http://www.EarthLink.net MIME-Version: 1.0 NNTP-Posting-Date: Wed, 10 May 2000 08:54:28 PDT Newsgroups: comp.lang.ada Date: 2000-05-10T00:00:00+00:00 List-Id: 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] -- > "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).