[LEAPSECS] the big artillery

[Dennis Ferguson]

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 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.

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.

There is some clear evidence that their concerns about having more than
one timescale distributed are well founded, e.g. Android phones on some
networks with clocks which were once 15 seconds off.  There is also
some very clear evidence, however, that UTC as it is defined now is
not right for the purpose, e.g. GLONASS which did the "right" thing
by using UTC as its system timescale and then suffered leapsecond
failures, and the recurring problems with NTP implementations.

I am old enough to have worked on ntpd when this one timescale
system still worked (as in, they could force it down your throat
whether you liked it or not, not as in, the software actually
worked).  In the late 1980's and early 1990's you could plug in a
radio clock and get quite good UTC, but the integer relationship
to TAI was harder to come by since it wasn't transmitted by the
radio services and the Internet wasn't a given then.  It would
have been hard to pick TAI, or anything other than UTC, as your
distribution timescale since nothing else was as reliably available.
When they told you "don't use TAI, we don't distribute it" they were
telling you the truth.  This changed only when they allowed civilian
access to GPS, the original failure, since then determining TAI was
trivial via a defined constant while UTC was the one that required
some work. Now, when they tell you "we don't distribute TAI", it is
quite reasonable to wonder just what the heck they are talking about.

I personally believe that that the design goal of having one
common timescale distributed is quite vital, that we would
probably come to regret doing anything else and that if you
choose TAI for your distribution timescale you are probably
making a mistake.  On the other hand, it is very clear that this
common timescale can't be UTC as it is now since the unwillingness
by many (with good reason) to use it for its intended purpose,
its failures, prove that it just isn't working.  A timescale
without leap seconds would fix it for those people, and maybe
even allow prior failures to be brought back into the fold with
creative paper epoch redefinitions.  As a practical matter,
though, this one timescale also needs to be the basis for civil
time since, while using a non-civil-time timescale for time
distribution and expressing civil time as by its relationship to
that is technically quite feasible (it is what GPS does, what you
might do with TAI, and how other "technical" timescales are
handled now) many national labs are explicitly paid to distribute
their country's civil time and might have trouble with doing so
less than directly, not to mention existing radio formats which
transmit the one true timescale with no code space for an offset.
I suspect the reason they call the gaggle of other timescales they
expect you to derive from the relationship to the transmitted
time "technical" is that only "technical" people who understand
what they're doing, and why, are supposed to be interested in
them.  This doesn't describe civil time users, so effectively
if there is to be only one distributed timescale it has to be
their timescale (and I also believe you are making a mistake if
you violate "distribute one common timescale", but with the
current state of things it probably is the (much?) lesser of
two evils).

And that is just too many constraints to be satisfied
simultaneously.  There is no possible solution that doesn't
involve forcing something new down someone's throat that they don't
like.  That's not new, since UTC as it is now and was before
that did that too, but that was at a time when people had fewer
choices beyond just eating what they were given than they do now.
There is no happy solution, though I'm not sure that any change
could be worse than what we have now.

Dennis Ferguson