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, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,9fbc059a74d74032 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-05-31 08:46:12 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!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: Thu, 31 May 2001 11:31:35 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9f5o4q$j97$1@nh.pace.co.uk> References: NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 991323098 19751 136.170.200.133 (31 May 2001 15:31:38 GMT) X-Complaints-To: newsmaster@pace.co.uk NNTP-Posting-Date: 31 May 2001 15:31:38 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:7938 Date: 2001-05-31T15:31:38+00:00 List-Id: O.K. See my other post above - I phrased my original statement badly. You are right that a measure of absolute seconds is going to remain constant. I was thinking with respect to computing those seconds relative to dates. We agree on a date/time to meet. You compute the seconds between now and then and I compute the seconds between now and then and we both delay N seconds. Your computation involves leap-seconds and mine doesn't. We've got a problem in that one of us will be there early. 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.991301489.12794.comp.lang.ada@ada.eu.org... > Sorry, no -- or at least at a different point. If we meet "1234567890 seconds > from epoch XXX" then no one will be early (if no one travels at too relativistic > speeds). The second is a well defined unit and there is no choice of > measurement. There is no leap second problem, if we use time differences to an > epoch. > If we don�t want any leap second tables or regular updates for them, then > requiring that only "event_start_time" is used is just what we need to do that. > > The leap second problem occurs if we use human oriented component times like > "5-dec-2011 14:23:22.5 UTC". Assume I could predict the time of the next earth > quake in San Francisco precisely to the millisecond (far future assumed). Then > I know when it will be -- but I don�t know how to tell it in component time > because of the future leap seconds decisions. > The leap second problem also occurs if someone uses varying length "units" like > "minute". If we start just a second before a leap second and add 3 seconds and > then one minute, we will not get the same result as if we add the minute first > and the seconds then. > > BTW: In the good old days unixes used to have a clock which was a "time > difference to an epoch". But the POSIX time_t values we have now are _not_ "time > differences to an epoch" -- they are just a tightly packed form of a component > time with the funny property, that it would designate a time difference if > there wouldn�t have been any leap seconds. > > ... > > 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 > > If Ada.Calendar.Time_Of is called with a duration 86400.0 and then > converted back with Ada.Calendar.Split, we will get a duration of 0.0 (ARM > 9.6(25)). So I think that Ada.Calendar cannot be used for computations if you > care for a second. > > Wilhelm >