On Mon 2003-07-07T14:07:10 +0100, Markus Kuhn hath writ:
> If you really want UT, then you usually want to have it with the best
> possible accuracy and prediction available of course, and there is no
> reason not to provide it.
Except that providing it will require a lot of work, obtaining it will
require new hardware, and using it will require more work. In the
absence of a mandate it does not look like the ITU will want to bother
doing the design work for the radio signals to contain those values,
and the IERS won't have the funding to implement the necessary
mechanisms for reliable distribution of the values.
> You want to have:
>
> - one time to label events, and that would then be TI
>
> - the orientation of the earth to point your satellite dish
> and calculate sunrise, and that you extract this from the best available
> earth-orientation parameter Taylor approximations
Agreed, and should it come to pass I will happily take the lead by
sitting down with the director, requesting funding for hardware and
software, building TI into the timestamps of all the systems, and
using UT1C into the telescope tracking software.
Still, if UT1C is provided in the radio broadcasts then civil entities
will also have a choice of TI or UT1C. If any new scheme does not
come with a sensible plan for how leap hours (or leap whatevers) will
eventually be handled, then some civil entities with foresight might
choose to keep their civil clocks on UT1C rather than force
unmitigated consequences onto their posterity.
> I don't see a need for anything in between, and neither could anyone at
> the Torino meeting when Dennis McCarthy brought up the subject of
> whether there should be a UT1C.
The current real-time predictions of UT1 - UTC are good to 100
microseconds, and that is 1000 times better than the DUT1 values which
are currently being broadcast. Except for purposes of research and
systems that directly involve earth rotation, I do not believe that
anyone could reasonably demand UT to better than 1 millisecond and
expect to be taken seriously.
Nevertheless, some civil entities which prefer UT might perceive
ongoing (sub)millisecond adjustments as chaotic, and they might create
their own form of UTC-like timescale by using UT1C to re-create
something like the current rules for UTC. That could lead to a
proliferation of UT-like timescales with varying leap sizes and
varying rules for applying leaps.
Most indications that we have are that the SRG does not want civil
entities to have a choice, nor even to be aware that the broadcast
time signals might have been changed. The objection in Torino to the
use of the term UTC for an atomic timescale is a major roadblock, for
on the face that seems to require the rewriting the language, if not
the operational characteristics, of almost every standard and system
interface definition in existence.
The SRG are right to be concerned about a proliferation of time scales
(indeed, the available record indicates that was one of the principal
motivators for considering changes to UTC in the first place). Any
change adopted by the ITU needs to be sufficiently satisfactory to
everyone that it will encourage civil entities not to consider
inventing any other timescale.
Questions remain:
How to create a mandate that any new form of TI-based broadcasts must
also provide the difference ( TI - UT )?
What form and precision of that difference ( TI - UT ) would be best?
How to prevent proliferation of timescales by entities who may not
believe the answer to the previous question?
Or will the SRG do as the CCIR committee did 33 years ago, ignore the
objections, and try to get the ITU to remove leap seconds while
preserving the name UTC?
There's nothing new here. These are the same old unanswered questions
from 3 years ago but with more pointed examples. Viewed from some
perspectives the current scheme for UTC seems preferable to change.
--
Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064
sla_at_ucolick.org Voice: +1 831 459 3046 http://www.ucolick.org/~sla
PGP: 1024/E46978C5 F6 78 D1 10 62 94 8F 2E 49 89 0E FE 26 B4 14 93
Received on Tue Jul 08 2003 - 01:22:49 PDT