On 2017-01-31 02:32 PM, Warner Losh wrote:
On Tue, Jan 31, 2017 at 12:13 PM, Brooks Harris <bro...@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 <t...@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@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
