[LEAPSECS] BBC radio Crowd Science

[Warner Losh]

On Fri, Feb 3, 2017 at 4:30 PM, Brooks Harris <brooks at edlmax.com> wrote:
> If its after the Leap Second then your method doesn't work directly; you'd
> need to figure it out and make an internal adjustment to the TAI-UTC value a
> second *before* its supplied to you, right? See what I mean?

That would be a problem, yes. However, how do you know it is a leap
second w/o TAI-UTC changing? You'll need that metadata from elsewhere.
To do the leap second correctly, though, you'd need some warning
before the leap second  that it will, in fact, be a leap second.

I'd love to know which spec actually states the offset changes where
you say, since it would resolve the ambiguity. Absent a spec, the
closest thing is decades of Bulletin C.

However, I owe Zefram an apology for being overly grumpy. I thought he
was being deliberately obtuse. In reality, his question TAI-UTC at
23:59:59 proved the undoing of what I was advocating. I'm sorry I
snapped at him. It was uncalled for.

The math works perfectly if you use 60 seconds for the length of the
minute before the leap second (the second he had in mind), and 61
after. Not very satisfying, and a hole I had missed. Thinking through
what that's the case was helpful. It makes some sense that this would
be the case since the leap second isn't part of UTC until it is
inserted. Instead of modify the method to cope, I concluded something
else. It shows the real crux of my misunderstanding of the nature
TAI-UTC.

The problem is a confusion between an interval in UTC time, and a
difference between two time scales when one of the time scales is
using a second label not in the other. A interval in UTC time is well
defined and unambiguous. Applying my method to that problem works
flawlessly (w/o the suggested 60s kludge above) for computation of
intervals within UTC time. Since it works there, one would think it
would be a good fit for TAI-UTC since that looks like an interval.

However, that's not what TAI-UTC actually is. It isn't an interval,
despite being subtraction of two times. They are exactly the same
time, so the interval between them is always 0. TAI-UTC is actually an
offset between two sets of second labels. One can do that math two
ways to get the offset: my way and the conventional way. After reading
the standard, which is silent on the issue, neither is inherently
right or wrong. It's unspecified in TF.460. However, decades of common
usage (Bulletin C) strongly suggests the more conventional way is
what's more accepted. Since there's weirdness in what I was
advocating, and since it flies in the face of tradition, I'll concede
the point.

Sorry for the noise.

Warner