[LEAPSECS] the big artillery

Warner Losh imp at bsdimp.com
Wed Nov 5 16:39:59 EST 2014


On Nov 5, 2014, at 10:54 AM, Zefram <zefram at fysh.org> wrote:

> David Malone wrote:
>> if you transmit a second boundary at what you later identify to be
>> the wrong time, you can correct for that in your paper estimate of
>> TAI(X) so that it does may not align with UTC(X).
> 
> That's not what I mean by TAI(k).  You're describing having two distinct
> time scale realisation efforts from one authority, but my situation
> involves applying a single realisation effort to both time scales.
> I define
> 
>    TAI(k) = TAI + (UTC(k)-UTC) = UTC(k) + (TAI-UTC)
> 
> It follows that
> 
>    TAI(k) - UTC(k) = TAI - UTC
>    TAI(k) - TAI = UTC(k) - UTC
> 
> (Around leap seconds, "TAI-UTC" in the above expressions must be
> understood to refer to the difference that is appropriate for the UTC(k)
> value in question.)

Except that’s not how others define it. Given that definition, our discussion makes
better sense now. FOO(x) is the FOO timescale as realized by x. You have to
have actual clocks or oscillators ticking the signals out. To while UTC(x) exists for
a large number of x, TAI(x) doesn’t. You can find the corresponding TAI time for any
x’s UTC(x) after the fact when  BIPM publishes the data.

What you should be writing is something more like TAI(UTC(x)) to denote that
you are deriving TAI form UTC(x), not that x is realizing TAI.

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20141105/3eacec96/attachment.pgp>


More information about the LEAPSECS mailing list