Re: Leap Seconds

[Wilhelm.Spickermann@t-online.de (Wilhelm Spickermann)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 2442 bytes --]


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