[LEAPSECS] BBC radio Crowd Science

Tue Jan 31 16:20:34 EST 2017

On 2017-01-31 02:53 PM, Warner Losh wrote:
> On Tue, Jan 31, 2017 at 12:41 PM, Brooks Harris <brooks at edlmax.com> wrote:
>> On 2017-01-31 02:04 PM, Warner Losh wrote:
>>> On Tue, Jan 31, 2017 at 11:58 AM, Brooks Harris <brooks at edlmax.com> wrote:
>>>> On 2017-01-31 12:33 PM, Warner Losh wrote:
>>>>> On Tue, Jan 31, 2017 at 7:54 AM, Steve Summit <scs+ls at eskimo.com> 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.
> All the specifications says is that positive leap seconds cause the
> minute to have 61s.
Yes, Or the day 86401, etc.
>
>>>> 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?
> It increments just prior to the positive leap second. It doesn't
> matter how you get the information. That's when the offset needs to
> change for the irregular radix math to work.
>
> Or put less authoritatively: why would it matter how you get the
> information? A second is either a leap second or it isn't, right? And
> the property of a second that makes it a leap second in UTC is that's
> when the offset changes against TAI.
>
> We know that
>
> UTC = TAI + UTC_OFFSET(TAI)
>
> Since UTC is an irregular radix, the math is a little complicated, but
> the only way for the above to work out is if UTC_OFFSET(TAI) changes
> at the start of the leap second. So going from 36 to 37, the way you
> get :60 is by subtracting 37 from TAI instead of 36.
Right. Well if you have TAI-UTC = 36 and a "IsLeapSecond" flag its just 
TAI-UTC = 36 + IsLeapSecond = 37.
>
>>> 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.
> It's the only way to encode one number such that the irregular radix
> math works out.
I think I'm going to need an example I can work through to fully 
understand you here. When you get a chance, or can point me to 
something, thanks.
> And treating a positive leap second 'special' that
> needs an extra decrement is isomorphic to changing the delta at the
> start of the second.
Ah, well the Leap Second is special, isn't it, even from the point of 
view of your "irregular radix
math"? You are detecting it by whatever means and then treating it as if 
the TAI-UTC value incremented and the start of the Leap Second so its 
convenient to your methods, right? I mean, how its detected and treated 
could be seen as an internal implementation choice.

My "IsLeapSecond" flag can also be generated internally so long as there 
is adequate metadata, either a IsLeapSecond or IsLeapSecondMinute, or 
IsLeapSecondDay or something. But in any case you still need the TAI-UTC 
value.

The simple TAIToUTCDemoConsole program is not exactly how I do it in 
more elaborate code, but, generally I aim to do everything with integer 
math and logic.

I wrote the little program to illustrate the resulting values, 
especially the UTC seconds value, to explain what I meant by the 
YMDhms(TAI) and YMDhms(UTC) and to stimulate just this convrsaion, thanks.

I've found the IsLeapSecond flag to be very helpful metadata, especially 
when a receiver of a timestamp is interpreting it. If its explicitly 
flagged it saves any processing to detect it.

>
>> 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?
> I think that the standard and standard math concepts of irregular
> radix would dictate all that.
I'm not sure of that. It seems to me you are viewing it through a 
"irregular radix math" lens, which I'm sure isn't bad, but its not the 
only approach.
> How you encode your internal tables is
> up to you, so long as they are isomorphic to what I'm saying.
Yes, I agree, any implementation could do it whatever way appropriate, 
but I'm not sure about the TAI-UTC update topic yet.

I'll bet we're getting the same results, at least as far as TAI 
seconds-to-YMDhms(UTC) is concerned. If we're not there's an 
interoperabiliy problem. Of course testing and verifying timekeeping 
algorithms is tedious. But maybe we could make up a couple test examples 
and give generating a few listings a go?

-Brooks

>
> Warner
>
>>>
>>>> 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
>>> LEAPSECS at leapsecond.com
>>> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>>>
>>>
>> _______________________________________________
>> LEAPSECS mailing list
>> LEAPSECS at leapsecond.com
>> https://pairlist6.pair.net/mailman/listinfo/leapsecs
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>