On 2017-01-31 08:21 PM, Steve Summit wrote:
Wow. This has been quite a thread.
I feel like I should apologize for my earlier contribution to it,
which presented a nice-looking, persuasive-sounding argument
which now looks an awful lot like it's... wrong.
Not at all. Its an informed contribution. And I think it's not "wrong".
At least not yet. I think its "right", so far. :-)
But it seems to
have temporarily taken in (at least) Tom Van Baak and Brooks
Harris,
Standby. And I'm not sure Tom and I are seeing it the same way, yet.
until we've all been set straight by the patient
explanations of Warner Losh.
Yes, thank you Warner, pleased to have your input.
My own errors were,
Standby. Not errors yet :-)
I think, partly due to confirmation bias:
I really wanted the answer to be that the TAI-UTC offset changes
at the *end* of the leap second, because it lines up with so much
else:
* it's what the standards (seem to) say
That's what I think, but, as I said, I want to be sure, and that experts
agree.
* it lines up with all the leap second tables out there, which
claim to list (for example) 2017-01-01T00:00:00 UTC as the
first instant of TAI=UTC = 37 (that is, the tables do *not*
typically list 2016-12-31T23:59:60)
Yeah, me too. I think its more straight forward, understandable, and
thus risks fewer off-by-one mistakes when doing table lookups.
* it just makes some kind of intuitive sense that TAI-UTC should
change at the end of the UTC day, exactly when everything else
is ticking over, not one second before that event.
Yeah, me too.
It strikes me as stonger than "intuitive sense". YMDhms representation
defines the second that is midnight, and that seems like a most
important point. Seems to me TAI-UTC is a natural part of that transition.
(But for the moment these are just laments and puzzlements;
I am not putting them forth as counterarguments.)
OK.
It also seems to me that this is not merely an abstract
theoretical argument; it can have practical implications.
Yes, I agree.
If I'm defining an interface which presents UTC and TAI-UTC
(so that my client can compute TAI if needed), or which presents
TAI and UTC-TAI (so that vice versa), if my client and I don't
absolutely agree on the value of TAI-UTC during a leap second,
someone's going to get the wrong answer.
(As but one example of such an interface, under Unix/Linux the
adjtimex system call can return both UTC time and a TAI offset.
In my tests I've found that the returned TAI offset value isn't
always strictly accurate, and I've been working to fix it, but
the intent of the code behind it seemed to match mine, i.e. to
change at the end of the leap second.)
Exactly places like that where I think this counts. Whole code
superstructures could be designed and written with the wrong underlying
objective.
What a puzzle.
The fog of UTC :-)
-Brooks
_______________________________________________
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
