On Wed 2006/01/11 20:58:25 PDT, "M. Warner Losh" wrote
in a message to: [EMAIL PROTECTED]

>:                         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

Reply via email to