[LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-02-06 12:11 PM, Warner Losh wrote:
> On Mon, Feb 6, 2017 at 6:39 AM, Zefram <zefram at 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