[LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-02-03 04:30 PM, Warner Losh wrote:
> On Wed, Feb 1, 2017 at 11:14 PM, Warner Losh <imp at bsdimp.com> wrote:
>> On Wed, Feb 1, 2017 at 10:37 PM, Zefram <zefram at fysh.org> wrote:
>>> Warner Losh wrote:
>>>> If you are going to willfully misunderstand, then I'm done being patient.
>>> I am not willfully misunderstanding.  I have tried to understand
>>> what you're doing, and I've been unable to find a system that works
>>> consistently, uses the labelling of leap seconds on which we are agreed,
>>> and yields TAI-UTC changing at the start of a positive leap second.
>>> Please enlighten me.  If you were to supply the couple of worked examples
>>> that I have suggested, I believe that would shed much light on your
>>> system.
>> I've already done exactly that. I'll see if I have time tomorrow to
>> write it up again using TeX or something that's easier to format and
>> explain with than ASCII text. Based on Tom's description of my method,
>> I think he may misunderstand it too. It's as consistent as the
>> calendar system we have today.
> I'm doing a longer write up, but work got crazy...
>
> But consider TAI and UTC when they were equal, for the sake of
> argument. I know they never were, but if we look at what the first one
> would look like:
>
> TAI                                      UTC                         delta
> 23:59:58                             23:59:58                    0
> 23:59:59                             23:59:59                    0
> 00:00:00                             23:59:60                    1
> (since how can it be 0 if they are different?)
> 00:00:01                             00:00:00                    1
>
> 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.
>
> It's understanding what the weird math is that I'm having trouble with
> for people that say it is after the leap second that the delta
> changes.
I guess that would be me, primarily.

(I see Stephen Scott has joined my opinion.. as I write this.)

I'm not questioning your logic or methods. I think I get it, though I 
haven't yet tried to work it through.

But it seems to me like the question is, from where and in what form are 
we obtaining the Leap Second metadata? And its here I feel like when the 
TAI-UTC (the "delta", as you say, if I'm understanding) updates (before 
or after the Leap Second) matters as interoperability issue.

If you're obtaining the data from an external source, such as loading a 
Leap Seconds table from somewhere, like Tz Database, you could arrange 
the data anyway convenient and query it anyway you want. But when 
reading a time dissemination protocol in "real-time" how is the Leap 
Seconds metadata organized and updated?

In 1588/PTP for example, 8.2.4.2 timePropertiesDS.currentUtcOffset, "... 
the value of timePropertiesDS.currentUtcOffset is the offset between TAI 
and UTC". But it does not, as far as I can tell or know, say *when* this 
value is to change, before or after the Leap Second. That's an 
interoperability issue, and its in discussions in that context I've 
reached my current opinion; you have to assume its intended to follow 
the "specs", and the spec(s) seem to say "after the Leap Second".

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?

-Brooks