I believe you're making a subtle error in your identification of UTC
seconds with TAI seconds.
And I in turn think you (or perhaps someone else)are making an error
in your use of the term "UTC".
A TAI clock aims to measure the current TAI time, i.e. to measure the
time interval between the epoch and _you_ in units of TAI seconds,
i.e. SI seconds as observed on the geoid.
In spatial terms, a TAI clock is analogous to a very precise measuring
tape which aims to measure the distance between you and an fixed
conventional point in space, analogous to the TAI epoch.
We agree so far.
In this analogy, a UTC clock is analogous to an equally precise
measuring tape that is _almost_ identical to the TAI analogue measuring
tape, but subtly different. If we place the two measuring tapes side by
side and ignore pre-1972, we see that the markings are in _precisely_
the same positions along the entire length of the tape, without the
slightest deviation, even over long distances.
The difference between the two measuring tapes is that they assign
different numbers to the markings, and moreover that the UTC analogue
has a small handful of places where two adjacent markings have the same
number assigned, and all subsequent numbers are shifted by 1.
Now I think you are entirely right here, modulo a single term: what you are
calling "UTC", I call (and I think correctly), "Posix". It is Posix time that
has two identical adjacent markings.
126230400 |------------
126230400 |------------
The numbers here are not UTC seconds since the Epoch, but Posix seconds
since the Epoch. In short, there are exactly 86400 Posix seconds in a mean
solar day, whereas in UTC reckoning there are exactly 1440 minutes, of which
some may contain more (or less) than 60 seconds. That is why UTC clocks
displayed 2016-12-13T23:59:60 during the last leap second. Computer clocks
are normally Posix rather than UTC clocks, and the difference does not matter
very often.
$1 = ((126230410 "1973-12-31T23:59:58Z")
(126230411 "1973-12-31T23:59:59Z")
(126230412 "1973-12-31T23:59:60Z")
(126230413 "1974-01-01T00:00:00Z")
(126230414 "1974-01-01T00:00:01Z"))
--8<---------------cut here---------------end--------------->8--
Good.
> If I understand correctly, 'time-utc->date' should never return a date
> object with 60 in the seconds field, because those extra seconds have no
> representation in time-utc. They only have representations in time-tai
> and time-monotonic.
Same story. Leap seconds have no representation in Posix time, but they
do in UTC time.
As you can see, 1973-12-31T23:59:60Z and 1974-01-01T00:00:00Z have the
same representation in TIME-UTC.
That is because what is called UTC time is in fact Posix time.
--
It was impossible to inveigle
Georg Wilhelm Friedrich Hegel
Into offering the slightest apology
For his Phenomenology. --W. H. Auden, from "People" (1953)