[LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-02-09 02:28 AM, Warner Losh wrote:
> 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.
Yes. The need for the metadata in some form is unavoidable because the 
Leap Seconds are irregularly introduced in the past (history) and 
unpredicatble when they will be introduced in the future (announce 
and/or expiration). That's the whole point of it. Its not just 
mathematical. Its an algorithm that is partly mathematically calculable 
for the Gregorian part, but also requires the additional UTC metadata as 
an input to arrive at UTC YMDhms (or the reverse). That's where I've 
called it an "encoding". I'm not sure "encoding" is the best term, but 
the best I've found. Writing about the stuff in prose is difficult 
because so many different terms are used by so many folks from different 
backgrounds.
> 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.
Yes. That's where I illustrated using an "Is Leap Second" flag. How an 
"Is Leap Second" condition is detected depends partly on what you're 
dealing with. If the complete Leap Seconds table, announce, and 
expiration are available to you its simple enough - the Leap Second is 
the second *before* the [UTC date][TAI-UTC] as presented by the Leap 
Second tables. But if you're dealing with a real-time time-link protocol 
(GPS, PTP, NTP) you're either dependent on the UTC metadata supplied by 
the time-link, or you need to go elsewhere somehow to collect it. 
Unfortunately, each of those protocols use slightly different formats 
and terms for the variables and not all carry the TAI-UTC directly, only 
announce flags. This situation is a result of historical development in 
an environment lacking clear specification.
>
> I'd love to know which spec actually states the offset changes where
> you say, since it would resolve the ambiguity.
I don't think there is any that states it unambiguously. As we've 
discussed, ITU Rec 460 doesn't state this, and BIPM Circular T and IERS 
Bulletin C only *imply* it by their [UTC Date][TAI-UTC] values. What 
you'd wish to find is a clear statement like "The TAI-UTC value shall 
update immediately after the Leap Second, coincident with the midnight 
rollover of the UTC YMDhms date". Seems to me the best place for a 
statement like this would be in Rec 460, and if it existed it would head 
off misunderstanding.

But there is much "common practice" that follows, or at least seems to 
follow, that interpretation. As I've said I've heard it discussed and 
the consensus was that interpretation.

The one place I've seen it made very clear is by David Mills regarding 
NTP, and he extends the analysis to POSIX. This is, off course, only 
David Mill's explanation, not a dues-process specification, but his 
considerable authority lends weight.

The NTP Timescale and Leap Seconds
https://www.eecis.udel.edu/~mills/leap.html

Figure 1. NTP Leap Second Numbering shows the "TAI offset" incrementing 
after the Leap Second

Figure 2. NTP Offset In the Vicinity of a Leap Second shows it 
graphically, and the TAI-UTC value incrementing after the Leap Second. 
However, even here there's a bit of vagueness; note that the arrow of 
the preceding TAI-UTC value does not extend through the Leap Second to 
the midnight boundary.

We're not the only ones confused about this, as you know - I found this 
discussion -

Re: [AVTCORE] Leap seconds
https://www.ietf.org/mail-archive/web/avt/current/msg14829.html

> 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.
Any technical topic is loaded with opinion and bias, but timekeeping is 
in a league of its own in eliciting passion and debate. Practical 
technical issues become entangled in discussions of Relativity, Quantum 
Mechanics, spirituality, mysticism, and cultural world view. Native 
languages add another level of potential misunderstanding. The standards 
are maintained by international standards bodies that contend with 
international politics and cultures which may add whole other levels of 
complexity not directly connected to the technical details.

For the most part those of us on this list are seeking academically 
correct practical technical solutions. The terms and expressions are 
important, and sometimes are misleading if we're not careful. I've been 
guilty of this too.
>
> 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.
I don't think its "noise". The discussion is at the apex of UTC 
timekeeping and is once again informative. It helps us all refine the 
ways we discuss it. Maybe, just maybe, if there were a consensus amongst 
experts it might somehow find its way its way to refinement of the specs 
themselves. How would you suggest, or imagine, the standards could be 
improved?

-Brooks