On Nov 3, 2014, at 3:35 AM, Zefram <[email protected]> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
