On 01/02/17 08:39 AM, Steve Summit wrote:
On further reflection, I think we're all right. For every
let's-look-at-the-arithmetic argument that suggests we should
use the "new" offset during the leap second, I can come up with
one which suggests the opposite. (Basically it depends on
whether you come at the leap second "from below" or "from above".
I'll send the longwinded details in a separate message, if anyone
actually cares.) So I'm right, and you're right, and Warner's
right, and Steve Allen is especially right in his assertion that
it's just inherently, fundamentally ambiguous.
The mapping between UTC and TAI is unambiguous. As Zefram pointed out
earlier, one second after the end of the leap we have
UTC=2017-01-01T00:00:01.0, TAI=2017-01-01T00:00:38.0. We can count
backwards by half seconds like so:
UTC=2017-01-01T00:00:00.5 TAI=2017-01-01T00:00:37.5
UTC=2017-01-01T00:00:00.0 TAI=2017-01-01T00:00:37.0
UTC=2016-12-31T23:59:60.5 TAI=2017-01-01T00:00:36.5
UTC=2016-12-31T23:59:60.0 TAI=2017-01-01T00:00:36.0
UTC=2016-12-31T23:59:59.5 TAI=2017-01-01T00:00:35.5
UTC=2016-12-31T23:59:59.0 TAI=2017-01-01T00:00:35.0
To determine the offset during the leap second we need to find:
2017-01-01T00:00:36.5 - 2016-12-31T23:59:60.5
I think the most reasonable interpretation of that offset is +36. But in
some sense it doesn't "really" matter, as long as whatever method you're
using comes up with the correct labels for the seconds.
Regards,
Eric
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
