[LEAPSECS] BBC radio Crowd Science

[Steve Summit]

John Sauter wrote:
> On Sun, 2017-01-29 at 15:33 +0000, Michael.Deckers. via LEAPSECS wrote:
>> My point was that Arias' labeling makes it clear that the
>> latest discontinuity in TAI - UTC occurred when TAI assumed
>> the value 2017-01-01 + 36 s. The ITU labeling (nor any
>> other specification in ITU-T TF.460-6) does not imply the precise
>> instant of the discontinuity, nor does IERS Bulletin C52.
> 
> Based on the definition of UTC, it seems to me that there are two
> cases, both of which are very simple.  For a negative leap second, the
> change in TAI - UTC happens instantly at UTC midnight, which is one
> second after 23:59:58, when the difference changes by -1.  For a
> positive leap second, the change happens gradually over the time of the
> leap second, from 23:59:60 to midnight, when the difference slowly
> changes by +1.

Perhaps I'm missing something, but I've always thought the
instant of the change was unambiguous, and that it was
instantaneous in both cases.

Positive leap second:

	TAI           UTC           TAI-UTC
	00:00:34.0    23:59:59.0    35
	00:00:34.5    23:59:59.5    35
	00:00:35.0    23:59:60.0    35
	00:00:35.5    23:59:60.5    35
	00:00:36.0    00:00:00.0    36
	00:00:36.5    00:00:00.5    36

Negative leap second:

	TAI           UTC           TAI-UTC
	00:00:33.0    23:59:58.0    35
	00:00:33.5    23:59:58.5    35
	00:00:34.0    00:00:00.0    34
	00:00:34.5    00:00:00.5    34

I've only shown half-second increments, but in the limit, in the
positive case, TAI-UTC would be precisely 35 for every instant of
the second numbered 60, and changes to 36 at the first instant of
00:00:00 UTC.  Similarly, in the negative case, it's 35 for all
of 23:59:58, and again changes at the first instant of 00:00:00.

Here we see what I would consider the desirable properties: TAI
is continuous, UTC and TAI-UTC are not continuous, and TAI-UTC is
always precisely TAI minus UTC.

The implication is that the essential discontinuity happens
precisely at the boundary between two UTC days.  (For me this
helps explain the oddity that leap second tables typically list
the days *after* what feels like the leap second days: the tables
list the first instant of each new TAI-UTC value, which ends up
being the instant after the "essential discontinuity".)

But perhaps I'm rehearsing the very obvious, and Arias and the
rest of you are dissecting a more subtle point that I'm missing.