[LEAPSECS] BBC radio Crowd Science

[Warner Losh]

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.

Warner