On Sun, Jan 22, 2006 at 12:13:38AM -0500, Tim Shepard wrote:
> > TAI is specifically contraindicated as a time scale.
>
> and
>
> > TAI is not currently recommended by its creators as a viable time
> > scale.
>
> I would love to know why.
Right. These statements are in direct contradiction to the report of
the CCTF in 1999. And as recently as last year, the United States
Naval Observatory discussion of the options noted the benefits of
using TAI. I've included references and excerpts below.
-CCTF-
http://www.intec.rug.ac.be/ursi/A_97-99.htm
...
7. THE 14th MEETING OF THE CCTF ( CONSULTATIVE COMMITTEE ON TIME AND
FREQUENCY), BIPM, SEVRES, 20-22 APRIL, 1999 ------- J. Steele
An additional output was a circular letter from the Director, BIPM,
emphasising the utility of TAI, as opposed to UTC, for systems
requiring uniform time, i.e. free from the discontinuities arising
from the application of leap seconds.
...
There was no consensus within the CCTF for any proposal to change the
definition of UTC. Instead, I was asked as Director of the BIPM to
draw your attention and that of agencies developing satellite
navigation systems, to the option of using TAI which is, of course an
international uniform time scale. I remind you of the ITU
Recommendation ITU-R 485-2 (1974-1982-1990) in which it is
recommended that "time data should be issued wherever possible either
with reference to Coordinated Universal Time (UTC) or to
International Atomic Time (TAI)". It is clear that if the leap
seconds of UTC cause problems in any particular application, the
preferred alternative is TAI.
The CCTF recommends, therefore, that in conformity with this ITU
Recommendation developers of future satellite navigation systems and
electronic communication systems should link their time scales to TAI
as the only alternative to UTC and that, insofar as it is feasible,
existing systems take steps to align their time scales with TAI. This
is in conformity with the CCDS Recommendation S4 (1996) on the
"coordination of satellite systems providing timing", in which it was
recommended that "the reference times (modulo 1 second) of satellite
navigation systems with global coverage by synchronized as closely as
possible to UTC. To facilitate the direct use of TAI for satellite
navigation systems, the time community is willing to take any steps
that are necessary to make TAI easily accessible to users. UTC
remains the basis for worldwide timekeeping, but TAI is recommended
for those applications requiring uniform time. I urge you to take the
necessary steps to inform your constituents of the characteristics of
both UTC and TAI so that appropriate use may be made if these
international scales. I enclose a few documents that may be of help
in this respect.
-USNO-
UNITED STATES NAVAL OBSERVATORY Circular 179 2005 Oct 20
http://aa.usno.navy.mil/publications/docs/Circular_179.html
For scientific instrumentation, the use of TAI which is free of leap
seconds has much to recommend it. Its seconds can be easily
synchronized to those of UTC (only the labels of the seconds are
different). It is straightforward to convert from TAI to any of the
other time scales. Use of TAI provides an internationally recognized
time standard and avoids the need to establish an instrument-specific
time scale when continuity of time tags is a requirement.
> ...
> I think we should stop arguing about what other people should use for
> a time scale and simply distribute both TAI and UT. I believe both
> kinds of time scales are needed. Some cases only need one kind,
> other cases need only the other kind. So distribute both and be done
> with it. Computers getting time over the net should make both kinds
> of time available to programs. (Why not?)
The issue comes down to what the "Civil" time standard is. If it is
changed to a uniform scale like TAI, we will need broad worldwide
consensus, and a lot of lead time.
But regardless, we need to make TAI available more easily.
Neal McBurnett
http://bcn.boulder.co.us/~neal/
Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60
Received on Sat Jan 21 2006 - 22:20:17 PST