On 2017-02-09 02:28 AM, Warner Losh wrote:
On Fri, Feb 3, 2017 at 4:30 PM, Brooks Harris <[email protected]> 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
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
