On 2017-02-06 12:11 PM, Warner Losh wrote:
On Mon, Feb 6, 2017 at 6:39 AM, Zefram <zef...@fysh.org> wrote:
Warner Losh wrote:
So either there's some weird math that lets one subtract two numbers
that are different and get 0 as the answer, or the delta has to change
at the start.
To the extent that they're different, the things being subtracted are
not numbers. The expression "TAI - UTC" is shorthand for something more
complicated than a numeric subtraction, which will nevertheless produce
a numeric result. The linear reduction of a timestamp that Clive and
I have separately described is sufficiently numerical to admit of a
straightforward subtraction, and the linear reductions of N:23:59:60 and
(N+1):00:00:00 are duly the same.
Saying that the two numbers are the same is improper. Or rather, it
depends on which time scale you are looking at them in if they are
improper. In UTC they are clearly not the same, but different second
labels. UTC can express this non-sameness. TAI can't do that, so you
have to reduce the improper time to a proper one before you can
compare them. There's two ways to look at it: convert them both to TAI
or convert them both to UTC.
So, if you look at the two times in TAI land, you have to do that
folding of seconds that's implicit in the linearization formula. If
you do that folding of seconds, then the 60 in the irregular radix
takes care of the difference in the first second since you've folded
its value to the value of the first second of the next day. That means
you have to say the difference starts after the leap second.
However, if you look at the two times in UTC land and compute a delta
in UTA land, then you find the interval between N:23:59:60 and
N+1:00:00:00 you wind up with 1 second. That leads to the conclusion
that the difference starts at the beginning of the leap second.
The whole discussion about when the difference starts can be boiled
down to that. What's the proper way to look at it? Depends on how you
do the math to do the conversion to when you use the new offset.
An analogy: suppose we do a bit of arithmetic in hexadecimal. We can
all agree that 0x5a0 - 0x5a0 = 0x0. Suppose that while keeping the
hexadecimal radix we additionally use the digit "g", with value sixteen.
Now we find that 0x5a0 - 0x59g = 0x0. The difference is zero, yet the
numbers appear different. What's going on? Well, the numbers per se
are the same: 0x5a0 = 0x59g is a single numerical value. The things
that are different are the digit sequences "5a0" and "59g", which under
the convention being used here are two different ways of expressing that
single number. The digit sequences are not themselves numbers.
I think now you're getting confused about irregular radix. If we were
to do that with hex, the number 0x59g would be a non-normalized number
that normalizes to 5a0 because hexadecimal is a regular radix. You
can't normalize N:23:59:60 to N+1:00:00:00 because in UTC they are two
different second labels.
Put another way: it's indisputable that if I have one event at
N:23:59:60.1 and a second event at N+1:00:00:00.6, they happened 1.5s
apart.
Also, I'll note that bulletin C says from 0h, which is a time
expressed to only one significant digit.
Oh yeah. Good point. For me, a case of "filling in facts from common
understanding". I immediately interpret "0h" to mean "00:00:00". Maybe not?
They chose to not use the
unambiguous 00:00:00 opting for the less precise 0h.
But its unclear if it was an intentional choice. Maybe they do mean
"00:00:00" by "0h"?
There are lots of places in many specs everywhere where things are not
fully spelled out. Sometimes its unclear if this is just due to slightly
careless nomenclature. There's a tendency to try to write prose
concisely, and sometimes this leads to something less clear than it
should be. If you've been in debates in standards bodies you know what I
mean. Writing standards prose is hard, and people don't always agree on
writing style, etc. especially when some participants are not from
native English speaking countries. The UTC specs have that challenge in
spades, so we could be seeing some effects of that in the English prose.
If you make the
second folding argument via time linearization, you map both the leap
second and the first second of the next day to the same value. Which
one of those is 0h?
I think the final answer is: It's ambiguous and I was wrong to insist
that there's one true way to recon it.
Who ya gonna call? It would be helpful if someone from BIPM, IERS, or
ITU would weigh in on the topic.
Another way to answer the question is to ask what's the common practice?
In my discussions regarding 1588/PTP the consensus was "the spec says
after the Leap Second" and most in the 1588/PTP community interpreted in
that way, that implementations would increment the
timePropertiesDS.currentUtcOffset after the Leap Second, the same
instant timePropertiesDS.leap61 would be set FALSE. The SMPTE specs
based on 1588/PTP make this same assertion. If its wrong we (SMPTE)
ought to figure that out soon. What does PTPd do?
I'm not a GPS expert. IS-GPS-200G is dense. The TAI-UTC value is
signaled, but how its encoded is complicated, and when its updated is
unclear to me. See 20.3.3.5.2.4 Coordinated Universal Time (UTC). Can
anyone speak to that and this topic? What does GPS do? Is it clear? Or
does it actually suffer from this same ambiguity we are discussing?
Also, NIST Special Publication 250-67 NIST Time and Frequency Radio
Stations:
WWV, WWVH, and WWVB
Says, on page 49:
A leap second warning is indicated on the WWV/VH time code at bit 3. If
a one is present on
bit three, a leap second will be added to UTC at the end of the current
month (leap seconds are
added only at the end of June or December). The warning bit is set high
near the beginning of
the month, and immediately after the leap second is added, it is set
low, or to zero again.
This is another source I've used to conclude TAI-UTC update after the
Leap Second. WWVB doesn't carry TA_UTC explicitly, but this suggest they
interpret the change instant as after the Leap Second.
-Brooks
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
