[LEAPSECS] Terminology question
magnus at rubidium.dyndns.org
Wed Mar 10 19:19:23 EST 2010
Steve Allen wrote:
> On Wed 2010-03-10T22:01:50 +0000, Michael Deckers hath writ:
>> Yes, the relationship between UTC and TAI is simple.
> In the lingo of the atomic horologists I would say
> "the relationship between UTC(TAI) and TAI is simple."
> Here UTC(TAI) means "the version of UTC constructed
> in arrears by using the contents of Circular T".
> The relationship between any other realization of UTC
> and TAI is not simple.
Similarly, the relationship between UTC(TAI) or UTC(lab) is not simple
relative TA(lab). Again circular T needs to be consulted.
>> If I understand you correctly: my computer gives me UTC(my_computer)
>> and I can convert that easily to TAI(my_computer)
> In the lingo of the atomic horologists there can be only one TAI.
> There is no published entity such as TAI(anything else), and the
> transcripts of discussions indicate that people get chafed when anyone
> uses such a lingo.
What do exists is the use of TA(lab) and TAI-TA(lab), as found in the
second part of the circular T publication. So, he could crunch out
TA(my_computer) from UTC(my_computer) assuming he has correct
leap-second tables. TA(my_computer) is expect to be similar but not
If one should be picky, nobody really has UTC either.
>> I do not understand how the formal definition of UTC limits its
>> precision to 1 ms. UTC can be determined with the same
>> uncertainty as TAI.
> Yes, but only as of next month, when the next Circular T is published.
> That is unsuitable for an operational time scale which is needed now.
> I believe it is this distinction that prompted the creation of GPS
> time and BeiDou system time as opposed to calling those system times
> by any sort of name related to TAI.
Which would not help in stopping the proliferation of timescales as
being used as an argument of removing leaps-seconds to stop getting
various offset variants of TAI being used as nominal offset and rate of
various system time-scales. These systems does not for their own
operation depend on being able to refer back to BIPM TAI or UTC, but to
their appointed realization and then to their national standard of
choice, which could then provide traceability to BIPM TAI or UTC or any
other national standard. The traceability aspect is of interest in the
long-time supervision of the system and for a subset of the customers of
the systems, but not the bulk users in (near) real-time.
The next system could use just about any rate and epoch meaningful and
suitable for operation. Base unit may be 1 ffn and pi fn into year 2010
in UTC time-scale. That would be harder to work with than something
nominally being TAI-like, so it is not entierly unreasnoble that
TAI-like scale would be chosen. UTC has been chosen by GLONASS.
The circular T emission rate should not be the most limiting aspect, but
is a concern for long-time steering. Using a national lab as reference
> Also notice carefully that the ICD which defines GPS time indicates
> that it is based on UTC(USNO), not on TAI. I suspect that in the
> statutory language of its mission there is no requirement for the USNO
> to deal with TAI, only UTC. It is only the compliance with the
> treaties which brings them to contribute to TAI.
The GPS system time is steered towards UTC(USNO) to maintain the TAI-GPS
offset to within 1 ms of 19 s. The effective steering is much better
such that. Individual satellite clocks is corrected into GPS system
time, and the USNO corrections allow for TA(GPS/local) and
More information about the LEAPSECS