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=-2.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM, MAILING_LIST_MULTI,PP_MIME_FAKE_ASCII_TEXT autolearn=ham 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 02:31:31 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed00.sul.t-online.de!t-online.de!newscore.gigabell.net!isdnet!enst!enst.fr!not-for-mail From: Wilhelm.Spickermann@t-online.de (Wilhelm Spickermann) Newsgroups: comp.lang.ada Subject: Re: Leap Seconds Date: Thu, 31 May 2001 11:27:31 +0200 (CEST) Organization: ENST, France Sender: comp.lang.ada-admin@ada.eu.org Message-ID: Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Trace: avanie.enst.fr 991301490 58735 137.194.161.2 (31 May 2001 09:31:30 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Thu, 31 May 2001 09:31:30 +0000 (UTC) To: comp.lang.ada@ada.eu.org Return-Path: X-Mailer: XFMail 1.4.0 on Linux X-Priority: 3 (Normal) In-Reply-To: <9f3fmc$o0f$1@nh.pace.co.uk> X-Sender: 0211750756-0001@t-dialin.net Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0.4 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: comp.lang.ada mail<->news gateway List-Unsubscribe: , List-Archive: Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: archiver1.google.com comp.lang.ada:7917 Date: 2001-05-31T11:27:31+02:00 On 30-May-01 Marin David Condic wrote: > 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? 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