[LEAPSECS] the big artillery

[Warner Losh]

On Nov 3, 2014, at 3:03 PM, Dennis Ferguson <dennis.c.ferguson at gmail.com> wrote:

> 
> On 3 Nov, 2014, at 07:13 , Warner Losh <imp at bsdimp.com> wrote:
>> TAI is a paper clock. You can convert your time stamps you get today from
>> your atomic clock to TAI time stamps once the offsets (phase and frequency)
>> have been determined for your clock by comparing it to all the others in
>> the data that makes up this paper clock. Until then, you can only have
>> speculative or preliminary values. For most people, I’ll agree this doesn’t
>> matter (+36s or whatever the current offset is). For some it is quite important.
>> 
>> UTC is also a paper clock. However, this paper clock has actual clocks that
>> are tightly steered to it that people can exchange time with to steer their clocks
>> to it. That’s why the recommendations are to use UTC time.
> 
> ?? UTC is defined by an integer relationship (the leap second count) to TAI.
> That's an exact, defined relationship; it is perfect by definition.  The
> clocks that produce UTC are the same clocks that produce TAI.  A clock that
> is steered to UTC is also being steered to TAI (less an integer number of
> seconds).  If you know UTC with some precision, and you know the current
> value of the integer, you know TAI with the same precision.  This isn't like
> the relationship between, say, TT and TAI, which is a nominal constant but
> which can in fact vary a bit (by the defects in the realization of TAI) since
> TT has its own physical definition while TAI incorporates its own defects.
> UTC also incorporates TAI's defects.  If you know UTC and you know the
> integer there is no way to not know TAI.

I think there’s an ambiguity in the language, and perhaps I’m splitting too fine a hair.

UTC(foo) is generated by the foo national labs based on steering an ensemble of clocks to what they thing UTC should be. I believe that makes it a paper clock, since it is a signal generated and steered to a number of source clocks. My understanding of the term, though, is based on engineering computer systems to steer and measure clocks, not on a PhD. Users can only get UTC(foo) or a signal derived from UTC(foo) (e.g., traceable to NIST) and never UTC itself. Of course they can get to a putative TAI(foo) trivially (I say putative, because as far as I know, no lab generates TAI synchronized signals for reasons you go into). However, they cannot get back to TAI(BIPM), which never generated in real time, but only computed after the fact when the various foos that create UTC(foo) and measure against each other report their measurements to BIPM. The national labs then use this data to steer their UTC(foo) signals to more closely match the presumed evolution of TAI(BIPM).

That’s the hair I’m trying to split. Sorry if this was ambiguous, but when recovering time signals, the source is important. I believe I even said for most users this difference won’t matter. This difference, though, is one of the reasons I think that use of TAI is strongly discouraged, but I have no documentation to back this up. Only engineering experience and reading the tea leaves of many of the statements that Steve Allen has dug up.

> I think the real issue relates to the criteria used for the design of UTC.
> Steve Allen listed two of them from an ITU document but the paper by Essen
> here
> 
>    http://www.leapsecond.com/history/1968-Metrologia-v4-n4-Essen.pdf
> 
> includes the third in section 4.  Cutting and pasting:
> 
>   Atomic time has been introduced into time signal services with the
>   following aims in mind:
> 
>     a) To make the full accuracy of the atomic clock widely and immediately
>        available.
>     b) To avoid confusion by having two separate systems of time signals.
>     c) To maintain the time scale made available by the signals sufficiently
>        near to UT2 for navigators who might not have ready access to
>        published corrections.
> 
> b) is the problem.  The idea is that everyone, everywhere, who transmits
> time signals should transmit the same time scale so that, which ever source
> you use, you get the same time with no ambiguity about what time that is.
> This doesn't deny the plethora of other "technical" timescales which are
> used, but providing these is supposed to be by done by expressing their
> relationship to the one that is transmitted ("published corrections") so
> that we end up with a system where just one timescale is distributed
> and everything else is determined by its relationship to that.

Strong agreement that (b) is the problem. Also agree with your conclusion below.

> From the little I know they still take this design very seriously.
> This means that every use of a timescale other than UTC for transferring
> time is really considered to be a failure of UTC.  GPS time is a
> failure, Beidou time is a failure and any use of TAI for time
> distribution is a failure.  There is no reason you can't distribute
> time in TAI, they just don't want you to do it and maybe have some
> good reasons for that.

Yes, there are many reasons. Ambiguity is one. I believe others may be tied to the tendency of engineers to get lost in the details and know two things aren’t exactly the same, so you should use one over the other. Even when the error introduced is so small as to not be of importance to anybody outside those folks who need 1e-15 or better, or folks that design time scale steering algorithms. There’s a widely recognized flaw in BIMP’s steering of TAI such that a drift between it and TT can be observed still. See ftp://tai.bipm.org/TFG/TT%28BIPM%29/TTBIPM.13 for a tabulation of the drift — it is getting much better, but there’s still some slope to the error plot, but is now ~1us / year where in years past it has been substantially worse. This is ~1e-14 over a time base of ~1e8 seconds.

<snipped — long detailed list of reasons UTC is painful to use, but also painful to switch away from>

Don’t forget LORAN time, which switched to pure atomic in 1972 because they didn’t want the headaches of leap seconds… :) They were the first to be uncomfortable with leap seconds...

> There is no happy solution, though I'm not sure that any change
> could be worse than what we have now.

Years of being on this list, and others, compel me to agree violently with this, and many of the excellent points you’ve made.

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/20141103/41729044/attachment-0001.pgp>