Re: Leap Seconds

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

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" <dennison@telepath.com> 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