# Re: The real problem with leap seconds

```In message: <[EMAIL PROTECTED]>
Mark Calabretta <[EMAIL PROTECTED]> writes:
: On Wed 2006/01/11 10:47:25 -0000, Michael Deckers wrote
: in a message to: LEAPSECS@ROM.USNO.NAVY.MIL
:
: >   At some instant when TAI took a value in the positive leap second between
: >   2006-01-01 + 00 h + 00 min + 32 s and 2006-01-01 + 00 h + 00 min + 33 s
: >   (the exact instant is not clear from [ITU-R TF.460-6 2002]), DTAI jumped
: >   from 32 s to 33 s; thus, UTC is not a monotone increasing function of
: >   TAI either.
:
: Here in a topology-free way is what the axis labels of my graph look
: like during the said leap second insertion:
:
:             UTC axis                    TAI axis                 DTAI
:        2005/12/31 23:59:58         2006/01/01 00:00:30            32
:        2005/12/31 23:59:59         2006/01/01 00:00:31            32
:        2005/12/31 23:59:60         2006/01/01 00:00:32            32
:                         60.9                        32.9          32
:                         60.99                       32.99         32
:                         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?  That's the point of
the leap second...  Or is that only needed when you do the POSIX
time_t thing of repeating 59?

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

: The only difference between UTC and TAI is one of representation, like
: the current year which may be represented as 2006 or MMVI but it's still
: the same year.

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.  Of course there's an
implicit assumption that the conversion function is the same as
POSIX's time_t, otherwise you would be using TAI or a count of actual
seconds.  We call it PPSes or pulses at work to distinguish it.  We
label UTC time as having leap seconds swizzled in, and TAI time as
unswizzled.

Warner
```