Some personal notes on the Torino meeting

From: Markus Kuhn <Markus.Kuhn_at_cl.cam.ac.uk>
Date: Mon, 02 Jun 2003 17:58:36 +0100

I just came back from the ITU-R SRG 7A Colloquium on the UTC timescale
at IEN Galileo Ferraris, Torino, Italy, 28-29 May 2003.

Here are few brief personal notes, which are by no means intended to be
complete, accurate or unbiased in any respect. This is just a quick
attempt to dump some of my scribblings and thoughts here, and I hope
other attendants will do the same, to preserve a more complete picture.

The meeting was organized and chaired by Ronald Beard (US Naval Research
Labs) and William Klepczynski, both of the ITU SRG. There were about 38
attendants, whose backgrounds can be summarized roughly as time &
frequency metrology, astronomy, aerospace industry, satellite navigation,
and one computer scientist.

I was in general pleasantly surprised by the high quality of the
presentations and the scope and comprehensiveness of the discussion.

The first few talks included reviews and some first-hand accounts of the
history of time standards, and in particular of TAI and UTC. The
astronomical background was also covered, and in particular the state of
the art in UT1 prediction, including speakers from BIPM and IERS.

We heard for example details of the definition of UT1 and how it
approximates GMT, but can't do so exactly because of rather complex
reasons. We heard how TAI was started in 1958 and was set to match UT2
(as it was defined then) on 1 Jan 1958 as much as was practically
achievable at the time. TAI and UT1 will have drifted apart by about 30
minutes in the year 2600 and by about 60 min in 3000. Judging from past
IERS data, it seems feasible at present to predict UT1 over 2 years with
an accuracy of better than 600 ms, and over 3 years with better than
1000 ms.

After the introductory talks that presented the scientific and historic
backgrounds, one of the first presentations that gave a case for
abandoning leap seconds was given by William Klepczynski. He took the
ADS-B (Automatic Dependent Surveilance Broadcast) system as an example,
in which GPS receivers installed in civilian aircraft broadcast their
own position and velocity vectors, such that any receiver can implement
a "virtual radar" from this data. He gave ADS-B as an application
example, where a high-precision time scale has (or is about to) become
an element of a real-world safety-critical air-traffic control system,
and where the parallel use of several time scales such as UTC and "GPS
time" could lead to rare and difficult to test malfunctions related to
UTC leap seconds. UTC would be used to display data to operators
(pilots, controllers) in real time, but a uniform timescale will also be
needed to solve motion equations. One claim made was that in many
real-world systems that run on UTC, the insertation of the leap second
is today actually delayed until the current operation has finished. This
leads temporarily to a loss of synchronization by one second for some
time after each leap second.

Throughout the presentations and discussions, it became clear that
people present were only aware of one single documented incident in
which a leap-second appears to have contributed to a severe disruption.
In the early 1990s, the Russian GLONASS navigation system, which is
internally based on the UTC timescale, became unavailable for 20 hours,
apparently due to a leap-second-related operator error. Details of the
incident seem not to be well documented and it appears that GLONASS had
no problems with more recent leap seconds.

Several of the talks proposed to set a dealine in the foreseeable future
(2022, the 50th anniversary of UTC was suggested), after which no
further leap seconds would be inserted into UTC. Several participants
expressed strong opinions on that after such a change, the resulting
time zone must not be continued under the name UTC, because the term
"Universal Time" in astronomical parlance clearly implies a close
coupling of a time zone to the earth's rotation angle. The name "Temps
International (TI)" was proposed, which is just TAI with the A dropped.
This new name has the advantage that it removes the technical
implementation of the time scale from TAI. If we stop adding leap
seconds to UTC in a decade or two and then rename the resulting time
into TI, we would get TI = TAI - x, where x is a small integer,
probabaly a bit above 40. A migration from UTC to TI would avoid the
about-one-minute jump that would be necessary if we moved from UTC to
TAI as the basis of civilian times.

One of the BIPM talks proposed to keep the UTC term in the interest of
diplomacy and merely relax the UTC tolerance to at least half an hour,
such that UTC could follow UT1 using leap hours. The first such leap
hour would be expected to become necessary near the year 2600. Various
people (including myself) voiced great concern about this variant in the
discussion and asked that if we really introduced a uniform (leap-free)
time scale, it should be _really_ uniform, and not just pile up the
problem into a larger one for future generations. In her reply, the BIPM
speaker agreed fully and admitted that the leap-hour proposal was more
meant as a political trick to move completely to a uniform leap-free
time scale, and that she herself did not consider planning what mankind
should do in 600 years from now practical.

One of the in my opinion strongest presentations was given by John
Seago, an orbital analyst with Honeywell. He presented the preliminary
results of a little study, of what cost |UTC-UT1| > 1 s would cause for
NASA and US DoD systems. He presented a convincing case for that the
costs are likely to be in the 100 million dollar range for _each_ single
mission-critical large-scale system, backed by by data from the Y2K
reviews, and the total cost to the US tax payer alone would be in the
order of half a billion US$. He listed numerous instances where the
assumption UTC ~ UT1 is built into a system, and where the current 900
ms tolerance is just about acceptable. Examples included satellite
tracking dishes, which need to know their own position on a non-rotating
geocentric coordinate system (-> derived from UT1), but where the beam
is wide enough to tolerate a 1 second error. Other examples included
radar calibration systems, missile early-warning systems, a widely-used
standard code for orbital analysis (SPG-4) and more. One of the
limitations of his study was that in many environments, even getting a
definitive answer to the questions whether |UTC-UT1| > 1 s could be
tolerated would cost substantial amount of money. Another problem he
faced was that many of the people he talked to didn't couldn't take the
issue seriously. John presented annecdotes about the ignorance, ridicule
and disbelief that he encountered when he approached colleagues to
gather data on the cost of decoupling UTC from the rotation of the
earth. He suspected that there will be far more severe resistance from
the aerospace industry against any change, once a specific and
believable proposal gets into a more advanced stage and people start to
understand that redefining UTC is actually a realistic prospect and not
just a purely academic phantasy discussion.

John also handed out a paper that he wrote after discussion with list
members on the role of UTC in national legislation. That paper had been
considered to be out of the scope of the colloquium by the organizers
and therefore did not feature in his presentation.

Daniel Gambis (IERS) presented the outcome of a survey among users of
the IERS Bulletins. In a nutshell, only about 5% of those who responded
want to change UTC, and the preferred options were roughly equally
spread over the alternatives offered in the survey, including options as
unrealistic and hopeless as changing the definition of the SI second.

Sidenote: Daniel later also mentioned in a brief discussion that some
people in IERS speculate that the next leap second might not be due
before 2006, because the Earth has surprisingly accellerated during the
past few years and as a result, the length-of-day is today roughly back
where it was in 1900. But Dennis McCarthy stressed that people should
_not_ take this prediction too seriously, because the recent
accelleration just demonstrates how unpredictable UT1 really is. Even
negative leap seconds cannot be ruled out.

Ron Beard outlined the ITU standardization process and emphasized that
all the SRG can do is to make a recommendation, and that then there
would be a lengthy ITU process during which a proposal that the SRG
might come up with would be presented to national member countries and
voted upon. If there would be any change, even the decision about what
will be done would be years away.

Patrick Wallace (Rutherford Appleton Laboratory, UK) suggested in his
presentation that we should go back to a 1960s style UTC that tracks UT1
more closely and smoothly, an option that Dennis McCarthy nicknamed UT1C
in his overview of the available options.

Judah Levine (NIST) talked about NTP and problems that have been
observed with the NIST NTP server in the context of leap seconds. The
ones he mentioned seemed to me though more like well-known deficiencies
in commonly used NTP clients that could be fixed with a bit more careful
programming, and not fundamental difficulties that normal workstation
computers have with leap seconds.

I also gave a presentation of leap second issues in distributed
computing, presented the UTS proposal and argued that something like it,
together with more carefully implemented NTP software, would in practice
eliminate computer worries about leap seconds, without a need to change UTC
arising from this area. I also argued that the message formats of
pre-GPS time broadcast services such as the various LF and HF time
stations leave much to be desired and that work on a globally
standardized state-of-the-art signal format would be a timely and
important project.
[http://www.cl.cam.ac.uk/~mgk25/c-time/torino2003/utc-torino-slides.pdf]

Finally, on the afternoon of the second day (Thursday, 29 May), the
agenda moved to writing up a draft conclusion of the colloquium, which
was then to be refined and phrased out more carefully by the
invitation-only SRG meeting on Friday.

Ron Beard with William Klepczynski drafted in PowerPoint on the
presentation laptop a list of objectives and conclusions for the
meeting. They started out with a few very pro-change statements, that
quickly attracted criticism from the audience as perhaps not being a
quite adequate reflection of the discussion at the colloquium.
Throughout the subsequent discussion, I had the impression that they
were rather happy to include pro-change arguments and statements that
were proposed by participants into the draft, but were very reluctant to
include any of the more sceptical/conservative statements that were, as
far as I could tell, proposed equally often. In the following coffee
break, a number of participants noted on their impression that the
organizers of the colloquium probably had already made up their mind on
the death of UTC and would push this through ITU in any case.

The concluding session was interrupted by a tour through IEN's time and
frequency labs, where we saw a caesium-fountain prototype, the Italian
master clock, as well as IEN's work on setting up a demonstration ground
segment for the Galileo project that at present uses the existing GPS
space segment.

During the tour, a number of other SRG members drafted a revised
conclusion that started with the much more cautious statement that there
was no overwhelming consensus on the need for replacing UTC with a
uniform time scale, which I felt much more happy with. When the meeting
reconvened, some minor changes were made on the included suggestion to
switch from UTC to a leap-second-free TI at some point. For instance,
Patrick Wallace insisted on putting 2022 as a suggested deadline in, to
allow plenty of time for existing systems to go out of service before
any changes take effect.

The SRG was going to meet on Friday morning to revise and flesh out this
concluding recommendation. I left Italy already Thursday evening and I
hope we will see the final result here sometimes this or next week.

Markus

--
Markus Kuhn, Computer Lab, Univ of Cambridge, GB
http://www.cl.cam.ac.uk/~mgk25/ | __oo_O..O_oo__
Received on Mon Jun 02 2003 - 09:59:01 PDT

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