[LEAPSECS] Terminology question

[Magnus Danielson]

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

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


> 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 
UTC(GPS/local) realizations.

Cheers,
Magnus