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,FREEMAIL_FROM, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,814bd9dd1692da42 X-Google-Attributes: gid103376,public From: Charles Hixson Subject: Re: Calling C time function from ADA-95 Date: 1998/06/09 Message-ID: <357DA2E1.704E9A16@earthling.net>#1/1 X-Deja-AN: 361156794 Content-Transfer-Encoding: 7bit References: <3579da75.13533758@enews.newsguy.com> <357C141E.D868661F@earthling.net> <6lhnan$1vi$1@goanna.cs.rmit.edu.au> <357D166E.685D7A09@cl.cam.ac.uk> <357D5083.45CB71F1@earthling.net> <357D6F53.46486039@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: http://extra.newsguy.com Newsgroups: comp.lang.ada Date: 1998-06-09T00:00:00+00:00 List-Id: Sure, it could easily be based on floating point numbers. And yes, I can write my own calendar package. Everybody seems to end up needing to write their own calendar. But doesn't that sort of defeat the purpose of a system library? Everyone could write their own sine_table package, too, but the system routine, being good enough, almost nobody does. If people are needing to re-implement the calendar, then that's a sign that the calendar package ... well, broken usually means something else. Markus Kuhn wrote: > > Charles Hixson wrote: > > I think that times should be kept on a kind of sliding scale. Say > > seconds for the current decade, minutes for the current century, hours > > for the current 100 centuries. Days for the current 10,000 centuries. > > Etc. > > That sounds like a revolutionary new concept, but somehow I remember > having heard one of our Computer Science professors telling us already > about such advanced mechanisms for representing scalar values. > Isn't this stuff called "floating point numbers" or so? :-) > > > That should be sufficient overkill for ANYONE that would be > > satisfied by the current date structure anyway. > > Just use a 64-bit integer counter for the seconds since some epoch, > which will last for the next 290 billion years (and goes backwards > far beyond the big bang). Add a 32-bit counter with the number > of nanoseconds since the last second started, and you get a > resolution that is an order of magnitude better than your CPU > frequency and the accuracy of good atomic clocks. The 32-bit > nanosecond counter has the nice property that inserted > leap seconds in your time scale (say UTC) can be represented > nicely as values 10**9..2*10**9-1. > > Markus > > -- > Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK > email: mkuhn at acm.org, home page: -- Charles Hixson charleshixson@earthling.net (510) 464-7733 or chixso@mtc.dst.ca.us