I don't know if you're getting all the posts to this thread, but I think if
you go back and re-read what I've said on the subject and what the original
problem is, you might have a better handle on what to address. Its already
been observed that you can't determine what the leap-seconds will be in the
future. The problem I had at hand was one where I don't have a network time
source or other sorts of data that would correct for leap-seconds. Your
comments are interesting but are not really addressing the problem. The
problem is one of computing seconds between two calendar dates (past or
future) and how to account for leap-seconds. If one has a clock available
that is correcting for leap-seconds, that's nice, but I don't. As far as I
can figure, there is no good answer to the problem except to know how many
leap-seconds actually occurred since their inception and there is no way to
know when they will occur in the future if your computations take you there.

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" <Wilhelm.Spickermann@t-online.de> wrote in message
news:mailman.991382224.2673.comp.lang.ada@ada.eu.org...
>
> On 31-May-01 Marin David Condic wrote:
> > 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.
>
> Hmm, none of us can compute the number of seconds before the IERS has
> determined all the leap seconds in that time range. Once the leap seconds
or
> their absence are determined, we will get the same results.
>
> > Your computation involves leap-seconds and mine doesn't. We've got a
problem
> > in that one of us will be there early.
> >
> But a look on the next wall clock will show, who computed the wrong result
(we
> agreed upon a specific date and time). None of us will be early, if we
interpret
> the results of the computation correctly.
>
> The computation which includes leap seconds will compute the time
difference and
> the result can be used in a simple countdown clock or (hopefully) a delay
> statement. The computation has to be postponed until the necessary
information
> is available.
>
> The computation without leap seconds can be done at once but it doesn�t
compute
> a time difference. But the result can be compared to a POSIX clock, as
this type
> of "clock" jumps with every leap second inserted or omitted. The result is
> unusable for delay statements. (I hope at least no one wants "delay 1.0;"
to
> mean "don�t wait" if its execution happens to fall on a negative leap
second.)
>
> Wilhelm
>