[LEAPSECS] the big artillery

[Warner Losh]

On Nov 3, 2014, at 3:35 AM, Zefram <zefram at fysh.org> wrote:

> Warner Losh wrote:
>> TAI and UTC have a fixed offset relationship, it is true. However, UTC is
>> computed in real time (with several varieties to choose from if you care
>> about the nano-seconds), but TAI is a retrospective timescale that's not
>> computed until after the fact.
> 
> These two notions conflict: a predetermined offset relationship means that
> TAI and UTC can be trivially computed from each other, which means that
> if one of them can be computed in real time then so can the other.  The
> reality is that the difference between TAI and UTC is indeed predetermined
> (and always integral seconds, post-1972), and *both* TAI and UTC are
> paper time scales that are canonically only determined in retrospect.
> Both have real-time realisations that differ by nanoseconds: each UTC(k)
> realising UTC implies, via the well-known offset, a corresponding TAI(k)
> realising TAI.  The notation "TAI(k)" isn't officially approved, but the
> concept is perfectly meaningful, these time scales are readily accessible,
> and they are de facto used in some applications.

Except it doesn’t work that way.

The TAI timescale, as maintained by BIPM, is computed well after the fact.
You cannot know it in realtime because it is not computed in real time. The
nominal offset from UTC is a fixed number of seconds, but UTC’s realization
differs from place to place. UTC realized from the labs of NIST will have a
small offset from the UTC realized from NRAO. Since TAI isn’t realized in
realtime anywhere, you can’t possibly steer to.

You can create your own TAI, that’s traceable to a government lab UTC, but
that’s not quite the same thing. You have TAI(joe-private-citizen) not TAI(NIST)
or TAI(BIPM).

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.

> There's a political shell game going on with some people trying to
> suggest that there's a significant difference here between TAI and UTC,
> trying to discourage the use of TAI by end users.  I can only guess at
> the motivation: perhaps an attempt to keep some of the conceptual space
> unsullied by the grubby mitts of actual applications.  Don't be fooled:
> real-time TAI realisation is available to the masses.

Well, you can create something that’s like TAI, sure. But BIPM’s TAI is
not a real-time thing. BIPM doesn’t want people to use it because they don’t
want the hassles of having a real-time operations time scale. Use UTC for
that, they say.

That’s why people should create a new name for UTC without leap seconds.
It isn’t UTC anymore (since it has lost the trait of tracking UT1), but it isn’t
TAI either since it is realized in real time. It is trivial, as you suggest, to have
a TAI-like thing that is good enough for everybody (basically UTC time-scale
for phase and frequency, but with TAI-second labels instead of UTC-second
labels). But that isn’t quite TAI, but is a quite useful concept. This is why we
have Loran time, GPS time, Galileo  time, etc. There was no foresight in the
1970’s to say “here’s the atomic time scale, here’s the rotational time scale
and operationally, here’s how you convert the latter to the former.” I wonder
if any of the list historians has a good reference to the proceedings, or if we’re
left to speculate. My speculation is that the folks that knew TAI couldn’t get
past these trivial technical differences and so blocked its use, not realizing
that that they could still have their own stand box timescale and provide
meaningful guidance for decades to come...

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/23d07167/attachment.pgp>