On Mon, Jan 30, 2017 at 2:39 PM, Tom Van Baak <[email protected]> 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 _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
