On Wed 2006/01/11 20:58:25 PDT, "M. Warner Losh" wrote
in a message to: mcalabre_at_atnf.csiro.au
and copied to: LEAPSECS_at_ROM.USNO.NAVY.MIL
>: 60.999... 32.999... 32
>: 2006/01/01 00:00:00 2006/01/01 00:00:33 33
>: 2006/01/01 00:00:01 2006/01/01 00:00:34 33
>:
>: The seconds keep step and the graph has no gaps, jumps or kinks.
>
>Shouldn't the DTAI increment for the leap second?
It goes from 32 to 33 at precisely 2006/01/01 00:00:00 (UTC) (or at
precisely 2006/01/01 00:00:33 (TAI) if you prefer), as shown in the
above table.
Refer to the last page of the current IERS Bulletin A, Vol. XIX No. 1,
ftp://maia.usno.navy.mil/ser7/ser7.dat, which says the same as above
though in a little less detail.
>That's the point of
>the leap second... Or is that only needed when you do the POSIX
>time_t thing of repeating 59?
My comments on discontinuity etc. do not apply to time_t which is not
the same thing as UTC.
>In computer science, regular things are easy. Irregular ones are hard
>and prone to errors. The :60 kludge makes a regular 1<->1 mapping
>function for time into a table driven nightmare :-(.
It sure does.
>The point isn't that one can construct a 'second labelling' that is
>unambiguous, monotonic and increasing, but rather that when one
>distills the UTC time down to a single number, you necessarily have
>ambiguities and discontinuties in that function.
time_t has ambiguities and discontinuties, but that is not a necessary
consequence of leap seconds. To their credit the CCIR did not stuff up
in specifying the clock notation to be used for UTC.
Mark Calabretta
ATNF
Received on Wed Jan 11 2006 - 20:50:31 PST