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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9fbc059a74d74032 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-05-30 12:08:32 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!fr.usenet-edu.net!usenet-edu.net!freenix!isdnet!psinet-france!psiuk-f4!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Leap Seconds Date: Wed, 30 May 2001 14:55:06 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9f3fmc$o0f$1@nh.pace.co.uk> References: NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 991248908 24591 136.170.200.133 (30 May 2001 18:55:08 GMT) X-Complaints-To: newsmaster@pace.co.uk NNTP-Posting-Date: 30 May 2001 18:55:08 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:7890 Date: 2001-05-30T18:55:08+00:00 List-Id: event_start_time is an absolute time measurement from a known epoch. The number of seconds since 1/6/80, 00:00:00 - *including leap seconds*. Failure to count leap seconds internally means that when event_start_time says "Noon Today" as a delta from the epoch, what you're really reading is "some number of seconds since XXX". If *you* count leap seconds and *I* don't count leap seconds and we agree to meet 1234567890 seconds from epoch XXX and *you* are throwing in a few extra seconds, I'm going to be early. See the problem? As I pointed out elsewhere, if you can do relative timing, it isn't an issue unless you are spanning leap-seconds. Also, if your accuracy requirement isn't that tight, then you can afford to have a discrepancy between the two. In this case, I'm not in trouble, but I'd like to be thorough so that in other areas that may use this time base, I've got the computations correct in the event greater accuracy is needed. Tucker Taft seems to indicate that there isn't anything in the standard or the validation suite to check for leap second computations. I'm inclined to believe him. Counting seconds in Ada.Real_Time has more to do with relative time computations than with dates, etc. It seems unlikely that the standard could require dealing with leap-seconds when there are very few systems (in the overall scheme of things) that would have up-to-date information about leap-seconds. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Wilhelm Spickermann" wrote in message news:mailman.991247484.29504.comp.lang.ada@ada.eu.org... > > > I fail to see the problem here. "event_start_time" allows to operate a clock > which just counts _every_ second and to compute correct time differences > without using any tables or corrections from outside. Its only problems are > conversions to and from human readable form -- but if noone is there to install > new leap second tables, then noone will request such conversions there. All time > stamps used in communication with the outside world would be "event_start_time" > values. > > One pitfall remains: Someone asking for something to be done every day > precisely at noon. Then you will have to convince her or him that a > precisely _regular_ interval would be much better... :-)) > > Ada support is found in Ada.Real_Time. If I interpret the ARM correctly, > Real_Time counts each and every second and so it has to count added leap > seconds and it may not count omitted leap seconds. So it just has an offset to > the event_start_time and perhaps some (solvable) computational problems as > real_time spans have a small guaranteed range (1 hour) compared to real_time > stamps (50 years from program start-up). > > Wilhelm >