Re: [LEAPSECS] Risks of change to UTC

From: M. Warner Losh <imp_at_BSDIMP.COM>
Date: Sat, 21 Jan 2006 00:03:26 -0700 (MST)

In message: <>
            James Maynard <james.h.maynard_at_USA.NET> writes:
: M. Warner Losh wrote:
: > : > If DUT1 is broadcast, then one can set the time keeping device to UT1
: > : > by a means similar to setting it to UTC, even if DUT1 exceeds 0.9s
: > : > with a similar accuacy (or better). There's nothing that says a watch
: > : > has to display UTC to be set correctly.

WWV and most of the world's time stations broadcast DUT1. I should
have added in my last message that some change in the signal format
would be necessary if the range of DUT1 exceeds 0.9s. Given a
sufficently long time horizon, this becomes a non-issue.

: You seem to expect celestial navigators to become more sophisticated in
: these matters of time scales than is presently the case. It would be far
: better, in my option, not to tinker with the definition of UTC and of
: civil time at all, but leave civil time zones tied approximately to UT1.

Maybe that is a reasonable expectation. Maybe it is not.

I will note that the profile of high precision time users has changed
since 1972 when UTC was invented. In 1972 celestial navigators were a
big part of the users of time. These days, they represent a much
smaller portion of that audience. If there are changes to how time is
provided, then all users of precision time should be considered.
Should we continue to tie our time up in knots because of a tiny
minority of users?

Maybe the answer that question is yes. Maybe it is no. However,
stating absoultely, unquestionably that it is one or the other is what
is wrong and what takes this discussion off into the weeds.

How many celestial navigators are there today?

: "There's nothing that says a watch has to display UTC to be set
: correctly." But then the user would have to carry two watches, one set
: to an approximation of UT1 (e.g., UTC + DUT1) and another set to civil
: time (TI, or local zone time, or whatever). For simpler, it would be,
: with far less impact on ordinary users of time, not to let UTC (or its
: replacement) differ from UT1 by more than the present +/- 0.9 s.

Over the next 50 years, these two watches will be well within the
tolerance of most normal watches. The approximation of civil time
will be less than one minute off during that time (if most of the
projections are to be believed).

If this is a real issue, the market will take over and produce watches
that have 'navigation time' and 'civilian time' at the touch of a
button. If you still desire to use older, purely mechanical watches,
then you must take extra steps, like knowing the current offset
between civil time and navigation time. Of course, purely mechanical
watches have other issues when used on a boat. Electro-mechanical
ones don't suffer those problems, but require some power source.

The foregoing assumes, for the sake of argument, that DUT1 becomes

: UTC is not broken. There is no need to "fix" it.

UTC works for navigation, but leap seconds pose problems for other
users of time. Stating absolutely that UTC is not broken ignores
these other users.

: > I'd also add that GPS receivers today already do exactly this sort of
: > correction when they decode the GPS time, but display the UTC time.
: True. But GPS receivers are electrically powered, and are not a fallback
: for the case when a boat's electrical systems fail. Nor are they a
: backup system for the case when the the boater is in proximity to a
: war zone where the U.S. DoD is jamming or degrading the civil SPS GPS
: service.

GLASNOS is a backup system to GPS that is not subject to DoD's
selective denial of signal. Soon, Galileo will provide additional
backup. Also, there's about a dozen time stations worldwide that
provide time signals today which can act as backup to GPS during a GPS
outage. I pointed out GPS more as an example of a 'clock that gets it
times in one timescale, but displays it in another' rather than as a
backup time source for your example mariner.

Received on Fri Jan 20 2006 - 23:03:56 PST

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