[LEAPSECS] BBC radio Crowd Science
Steve Summit
scs+ls at eskimo.com
Wed Feb 1 10:12:09 EST 2017
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.
More information about the LEAPSECS
mailing list