[LEAPSECS] BBC radio Crowd Science

[Warner Losh]

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.

Warner

Current TF.460: https://www.itu.int/rec/R-REC-TF.460-4-198607-S/en