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,7b69a8818c20ab9f X-Google-Attributes: gid103376,public From: Keith Thompson Subject: Re: Y21C Bug Date: 2000/01/04 Message-ID: #1/1 X-Deja-AN: 568302776 Sender: kst@king.cts.com References: <84nqbo$q28$1@nnrp1.deja.com> <84o0g2$u8v$1@nnrp1.deja.com> <84pvrs$7q1@ftp.kvaerner.com> <84t8qk$b9q$1@nnrp1.deja.com> <387246D7.8B1B2E8B@earthlink.net> X-Trace: thoth.cts.com 947018182 28362 198.68.168.21 (4 Jan 2000 20:36:22 GMT) Organization: CTS Network Services Newsgroups: comp.lang.ada X-Complaints-To: newsmaster@cts.com Date: 2000-01-04T00:00:00+00:00 List-Id: Charles Hixson writes: [...] > With 64 bit numbers available, I propose a new time standard, based > around 64-bit floats. We need a SMALL floating number (16 bits?) to > specify the millennium, and a large floating number (64 bits) to > specify the time. (0 = center of the millennium, +- 1 = +- 500 > years, etc.). Current Millennium = 2 (years 2,000->2,999, CE). (I > allow for a year 0 before the year 1, if you wish to print that out > as 1 BC, that's merely a formatting issue.) > > This would let us be as accurate as we have data available almost > all the time (i.e, creation of universe to end of universe [note: > the millennium was a floating point number]). Huh? I don't think that floating-point is appropriate for a time standard. The precision is too strongly dependent on how far you are from the arbitrarily chosen epoch. Floating-point arithmetic is notoriously tricky, which could be a serious problem if you want to check timestamps for equality, or reliably determine which of two files is newer. I also don't see the point of separating the millennium into a separate field, or even explicitly representing it. For 1-second precision, a signed 64-bit time_t orginating at Jan 1, 1970 can represent times nearly 300 billion years into the past and future. If one second is too coarse, a second 64-bit word can give you a precision of about 54 zeptoseconds (zepto means 10**(-21)). In Ada terms, this would be a 128-bit fixed-point type with a 'Small of 2**(-64). Conversion to and from a human-readable format is not difficult. In GNAT, I seem to recall that types Duration and Calendar.Time have the same representation, a 64-bit fixed-point type with a 'Small of 1.0e-9. That gives you nanosecond resolution over a range of times from about 1677 to about 2262. There are some fields for which that's insufficient, but for most applications it's more than enough. -- Keith Thompson (The_Other_Keith) kst@cts.com San Diego Supercomputer Center <*> Welcome to the last year of the 20th century.