[LEAPSECS] BBC radio Crowd Science

[Steve Summit]

I wrote:
> For every let's-look-at-the-arithmetic argument that suggests we
> should use the "new" offset during the leap second, I can come up
> with one which suggests the opposite.  (Basically it depends on
> whether you come at the leap second "from below" or "from above".
> I'll send the longwinded details in a separate message, if anyone
> actually cares.)

So here's that 2016-12-31 leap second progression again:

	row	TAI     	UTC     	TAI-UTC
	1    	00:00:35	23:59:59	36
	2    	00:00:36	23:59:60	36? 37?
	3    	00:00:37	00:00:00	37

Looking at row 1, everything makes sense.  We can compute
TAI - UTC = TAI-UTC; we can compute TAI - TAI-UTC = UTC; we can
compute UTC + TAI-UTC = TAI.  Everything lines up; everything
is consistent; TAI-UTC is clearly 36.  And similarly for row 3,
where TAI-UTC is just as clearly 37.

But, not surprisingly, row 2 is where everything gets crazy.
:36 is clearly one more than :35, and :60 is clearly one more
than :59, so all the math works out consistently if we keep using
a TAI-UTC offset of 36.  For example, since 00:00:35 - 23:59:59 = 36,
we would have to agree that (00:00:35 + 1) - (23:59:59 + 1) = 36,
meaning that 00:00:36 - 23:59:60 = 36.  This is what I meant by
"coming at it from below".

But if we come at it from above, starting on row 3, we just as
easily get the other answer.  :36 is clearly one less than :37;
:60 is (reasonably) clearly one less than :00.  So if 00:00:37 -
00:00:00 is 37, then subtracting one from both operands gives us
00:00:36 - 23:59:59 which must also be 37.  QEND.

If we try to convert TAI to UTC on row 2, I absolutely agree with
Warner that 00:00:36 - 36 looks like it ought to equal 00:00:00,
and that 00:00:36 - 37 has a much more likely chance of working
out to 23:59:60.  This is a persuasive, very nearly compelling
argument.  But when I come up at it from below, I can just as
persuasively and almost-compellingly convince myself that the
offset should be 36.

Part of the problem, as Zefram has pointed out, is that when we
attempt to compute 00:00:36 minus anything, we're subtracting a
relative time from an absolute TAI time, which gives us another
absolute TAI time, *not* a UTC time.  So the method is already
suspect.

The leapsecond-handling code I've been writing recently is based
around a table that can tell me, for a given (UTC) timestamp,
what the day length and TAI offset are for the UTC day containing
that timestamp.  Given that architecture, I pretty much have to
have the TAI offset for the last second of a leapsecond day
matching the other 86400 seconds on that day.  When, belatedly,
I attempted to write a TAI-to-UTC conversion function last week,
I had problems with the leap second; I had to introduce a
kludgier and less-obvious special case than I expected to.  I now
realize that Warner is right: if TAI-UTC were one greater during
that second, the code would be a little cleaner.  But (in my case,
at least) there would be a substantial, and considerably greater,
amount of code elsewhere that would end up substantially messier.

I'm beginning to suspect that the reason the Standards don't
clearly tell us what TAI-UTC is during a leap second is that all
the people who wrote those Standards went down the very same
roads we're going down now, and couldn't decide on a good answer,
either.