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-29 09:55:54 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: Tue, 29 May 2001 12:46:32 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9f0jpb$lnm$1@nh.pace.co.uk> References: <9elpii$30i$1@nh.pace.co.uk> <3B0ED67B.E40A4E06@averstar.com> <9f0ciq$itb$1@nh.pace.co.uk> NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 991154795 22262 136.170.200.133 (29 May 2001 16:46:35 GMT) X-Complaints-To: newsmaster@pace.co.uk NNTP-Posting-Date: 29 May 2001 16:46:35 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:7847 Date: 2001-05-29T16:46:35+00:00 List-Id: Well, its actually a "requirement" that is spelled out in a standards document that is not (yet) accepted by the FCC (AFIK). WRT "event_start_time", the standard says: "A 32-bit unsigned integer quantity representing the start time of this alert event as the number of seconds since 00 hours UTC, January 6th, 1980 with the count of interleaving leap seconds included." The situation is this: The source *may* be able to produce that time base & interleaving leap seconds. It would require a leap-second table that is periodically updated as new leap seconds happen - with the possibility that there is some delay between the leap-second and the table update. (In this app it isn't critical, but it might one day be critical in some other area...) The local time base is different and won't have access to any sort of leap-second update table. (Again, in this situation being off by a few seconds is not a big deal - but it might be in other parts of the application.) I can correct with a constant plus a "tuning" value sent from the source - if available - that represents leap seconds & hence we can be on the same time base. Hence a solution does exist. Back on topic: Since Ada doesn't promise anything about leap-seconds in the standard, I couldn't use it at the source or destination and just trust the compiler to get it right. Ada *might* get the leap seconds right if, for example, its time comes from the operating system and the OS is doing some sort of correction. I *know* my client side isn't going to have anything like that, so Ada unfortunately doesn't provide me with a nice, automatic answer. 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/ "Ted Dennison" wrote in message news:tKPQ6.3762$rn5.204359@www.newsranger.com... > In article <9f0ciq$itb$1@nh.pace.co.uk>, Marin David Condic says... > > > >Further research into leap-seconds indicates that effectively, they are > >unpredictable. The International Earth Rotation Service sort of announces > .. > >Now I'm wondering what I'm supposed to do with the requirement that I count > >them??? :-) > > I once worked on a project where we had a requirement to never loose an > inter-process message, and to hold the client and all recipients until we knew > it was received by all designated recipients. The more astute of you out there > will immediately recognise this as a variant the "Byzantine Generals Problem". > We were not so astute, unfortunatly. > > I find the best thing to do in these situations is to find some desirable extra > that you were going to add anyway, or would be trivial to add (there's always a > few of those once development starts), and "trade" it for the impossible > requirement with your customer. Do this after pointing out to them that they > have asked the physically impossible, preferably using supporting material from > scholarly sources (eg: the website you mentioned). This is also a good way to > get rid of other requirements that are way more expensive to implement than they > are worth (in that case, you use a good estimate of the financial impact of > adding the feature as your supporting material). > > --- > T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html > home email - mailto:dennison@telepath.com