[LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-01-31 02:32 PM, Warner Losh wrote:
> On Tue, Jan 31, 2017 at 12:13 PM, Brooks Harris <brooks at edlmax.com> wrote:
>> On 2017-01-31 01:52 PM, Warner Losh wrote:
>>> On Mon, Jan 30, 2017 at 2:39 PM, Tom Van Baak <tvb at leapsecond.com> wrote:
>>>>>> 2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5
>>>>>      What kind of arithmetic is that?
>>>> Hi Michael,
>>>>
>>>> First, there's no problem with this, right?  (Thanks to Steve for
>>>> catching typo)
>>>>
>>>> 2017-01-01T00:00:35.5 TAI = 2016-12-31T23:59:59.5 UTC
>>>> 2017-01-01T00:00:36.5 TAI = 2016-12-31T23:59:60.5 UTC
>>>> 2017-01-01T00:00:37.5 TAI = 2017-01-01T00:00:00.5 UTC
>>>>
>>>> Now, we want to use "UTC = TAI + (UTC - TAI)" notation. So which is
>>>> correct:
>>>>
>>>> 2017-01-01T00:00:35.5 TAI - 36 s = 2016-12-31T23:59:59.5 UTC
>>>> 2017-01-01T00:00:36.5 TAI - 36 s = 2016-12-31T23:59:60.5 UTC  ??
>>>> 2017-01-01T00:00:37.5 TAI - 37 s = 2017-01-01T00:00:00.5 UTC
>>>>
>>>> or
>>>>
>>>> 2017-01-01T00:00:35.5 TAI - 36 s = 2016-12-31T23:59:59.5 UTC
>>>> 2017-01-01T00:00:36.5 TAI - 37 s = 2016-12-31T23:59:60.5 UTC  ??
>>>> 2017-01-01T00:00:37.5 TAI - 37 s = 2017-01-01T00:00:00.5 UTC
>>>>
>>>> Neither one is particularly clear to me. Of course in real code it all
>>>> works because you special case the leap second label discontinuity and make
>>>> it work. In a sense you replace normal sexagesimal arithmetic with
>>>> 59-gesimal or 61-gesimal arithmetic for that one minute. But, yeah, I can
>>>> see that it complicates prose and equations regarding UTC-TAI offsets.
>>> I think it has to be the second one because when you work through the
>>> math, it works out.
>>>
>>> The math simply doesn't work out for the former. 36-36 is 0, which you
>>> have to somehow know means 60. That's nuts, imho. However, 36-37 is
>>> -1. When you have an underflow, you have to borrow from the previous
>>> minute. That minute has 61 seconds, which when added to -1 gives 60,
>>> which is the correct answer.
>>>
>>> Otherwise you are in special case hell where you know there's a leap
>>> second so you add one more, which is solved nicely by just bumping the
>>> offset at the start of the leap second.
>> Yes, I think I understand what you mean. Your take on it does simplify some
>> aspects of the math a bit, but, as I understand it, that's not what the
>> specifications say. Of course, as we've been discussing, the specifications
>> leave room for interpretation.
> Correct. They don't even talk about an offset. They just say that a
> leap second is counted positiviely 58, 59, 60, 00 and negatively 58,
> 00. Nothing more. And that if an event happens .3s into a leap second,
> it's label is mumble:60.3, or it it happens .1s a negative leap second
> it would be mumble:58.9.
>
>> I've been in long discussions on exactly this topic, and the conclusion was,
>> as I've said, TAI-UTC increments *after* the Leap Second.
> The math doesn't work out if you do that. It's certainly not what the
> standard says. Since the standard is silent on when the offset
> changes, the math of the situation must be controlling. I humbly
> submit that the logic that lead you the conclusion that TAI-UTC
> increments after the leap second is in error. It isn't supported by
> TF.460 (which is absolutely silent on the issue), and it isn't
> supported by the bare math of the situation when working with the
> numbers of an irregular radix in the typical way one does with dates.
True, Rec 460 is silent on it. But I think Bulletin C says the TAI-UTC 
value increments at the start of the day:

" UTC TIME STEP on the 1st of January 2017" and
"from 2017 January 1, 0h UTC, until further notice    : UTC-TAI = - 37s ".

It doesn't say "the second before 2017 January 1".

-Brooks
>
> Warner
>
> Current TF.460: https://www.itu.int/rec/R-REC-TF.460-4-198607-S/en
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>