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" <Wilhelm.Spickermann@t-online.de> 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
>