Re: [LEAPSECS] distribute TAI as well (was Re: [LEAPSECS] Risks of change to UTC )

From: Neal McBurnett <neal_at_BCN.BOULDER.CO.US>
Date: Sat, 21 Jan 2006 23:19:53 -0700

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.



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.



 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
Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60
Received on Sat Jan 21 2006 - 22:20:17 PST

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:55 PDT