[LEAPSECS] BBC radio Crowd Science

[Steve Summit]

Wow.  This has been quite a thread.

I feel like I should apologize for my earlier contribution to it,
which presented a nice-looking, persuasive-sounding argument
which now looks an awful lot like it's... wrong.  But it seems to
have temporarily taken in (at least) Tom Van Baak and Brooks
Harris, until we've all been set straight by the patient
explanations of Warner Losh.

My own errors were, I think, partly due to confirmation bias:
I really wanted the answer to be that the TAI-UTC offset changes
at the *end* of the leap second, because it lines up with so much
else:
* it's what the standards (seem to) say
* it lines up with all the leap second tables out there, which
  claim to list (for example) 2017-01-01T00:00:00 UTC as the
  first instant of TAI=UTC = 37 (that is, the tables do *not*
  typically list 2016-12-31T23:59:60)
* it just makes some kind of intuitive sense that TAI-UTC should
  change at the end of the UTC day, exactly when everything else
  is ticking over, not one second before that event.

(But for the moment these are just laments and puzzlements;
I am not putting them forth as counterarguments.)

It also seems to me that this is not merely an abstract
theoretical argument; it can have practical implications.

If I'm defining an interface which presents UTC and TAI-UTC
(so that my client can compute TAI if needed), or which presents
TAI and UTC-TAI (so that vice versa), if my client and I don't
absolutely agree on the value of TAI-UTC during a leap second,
someone's going to get the wrong answer.

(As but one example of such an interface, under Unix/Linux the
adjtimex system call can return both UTC time and a TAI offset.
In my tests I've found that the returned TAI offset value isn't
always strictly accurate, and I've been working to fix it, but
the intent of the code behind it seemed to match mine, i.e. to
change at the end of the leap second.)

What a puzzle.