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

From: Tim Shepard <shep_at_ALUM.MIT.EDU>
Date: Sun, 22 Jan 2006 00:13:38 -0500

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

The only hint of a reason I've heard on this list to explain why
would also seem to apply to UTC since UTC is defined in terms of TAI
ticks. (IIRC the reason was that TAI is constructed after-the-fact
from observations between the atomic clocks which are scattered at a
number of different locations around the world, so you can only know
what time it is TAI after the fact. Well, if that's the problem,
then UTC is not any better.)


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?)

If someone's best judgement is that one kind of timescale is for
their purposes better than the other, then they will be free to
exercise that judgement.


This also avoids the issue of agreeing when to make "the change".

UTC can continue to be distributed as it is. Improvements (e.g. to
distribute TAI as well, continuously broadcast a complete table of
historic and scheduled leap seconds, distribute a higher-precision
DUT1, etc.) can be made incrementally without causing a semantic mess
and without breaking any properly implemented existing systems.
We could start down this road without delay.


My hope is that proceeding down this path could make everyone happy.


                        -Tim Shepard
                         shep_at_alum.mit.edu
Received on Sat Jan 21 2006 - 21:24:19 PST