[LEAPSECS] BBC radio Crowd Science
brooks at edlmax.com
Thu Feb 9 11:23:58 EST 2017
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
> 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
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
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
Re: [AVTCORE] Leap seconds
> 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
> 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
More information about the LEAPSECS