On 2017-01-31 02:04 PM, Warner Losh wrote:
On Tue, Jan 31, 2017 at 11:58 AM, Brooks Harris <[email protected]> wrote:
On 2017-01-31 12:33 PM, Warner Losh wrote:
On Tue, Jan 31, 2017 at 7:54 AM, Steve Summit <[email protected]> wrote:
Tom Van Baak and Michael Decker wrote:
2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5
What kind of arithmetic is that?
I think it ends up being roughly the same kind of arithmetic
that tells you that the 60th day of the year is March 1.
Or maybe February 29.
Maybe he's referring to the fact that the offset is 37s, not 36s. The
offset changes AT THE START OF THE LEAP SECOND.
OK, now here's something I've been worrying about for a long time. Everyone
on LEAPSECS, and seemingly everywhere else in the literature, are *sure*
they know exactly what UTC with Leap Seconds is. Yet the specifications are
unclear, as we've been discussing.
Here you are saying "The (TAI-UTC) offset changes AT THE START OF THE LEAP
SECOND. " That is in direct conflict with my best understanding of it. I'd
say "The (TAI-UTC) offset changes immediately AFTER the Leap Second, at the
midnight roll-over to the first second of the next month." (See other email
with my explanation and demonstration code).
That code isn't doing what you think it is, at least imho. By knowing
it's a leap second and adding 1, you've just made a complicated
adjustment that would be unnecessary if the offset changes at the
start of the leap second. Effectively you've "corrected" knowing it's
a leap second by changing the answer by one. That's exactly the same
as saying the offset is one greater one second earlier and eliminating
the special case. In both cases, you have to know that the last minute
has 61 seconds.
Yeah, but I think that's what the specification say.
So, this is obviously a huge interoperablity issue. It has ramifications
through many aspects of timekeeping manipulations.
I don't think so. It's all about how you do the math and the final
answer.
I think its about how you *receive* the information too, not just the
YMDhms (UTC) result. What information is supplied by NTP or GPS? You've
got to know exactly when to apply the Leap Second. In the case of a
hypothetic Leap Second aware timestamp you need the metadata: TAI-UTC
and one of IsLeapSecond or IsLeapSecondMinute (like a "61" flag) or
IsLeapSecondDay. But the question is, on which timestamp does TAI-UTC
increment?
My interpretation leads to simpler math.
Simpler math for what purpose? A bit simpler to calculate YMDhms (UTC)
maybe, I'd have to work it through. Of course you can treat it anyway
you like internally as long as two applications wind up with *exactly*
the same results. But they have to agree when TAI-UTC updates, at least
as far as any interchange mechanism in concerned, right?
Ah, so who's right?
IMHO, if you do the math out long hand, you'll see I'm right. See
other mail where I walk through it (though perhaps in a difficult to
follow way due to the limits of email).
Warner
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
