On 2017-02-03 04:30 PM, Warner Losh wrote:
On Wed, Feb 1, 2017 at 11:14 PM, Warner Losh <[email protected]> wrote:
On Wed, Feb 1, 2017 at 10:37 PM, Zefram <[email protected]> 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
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
