[LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

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 at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>