> First risk - do all airlines and shipping lines automatically hew to
> NT for all purposes? Or will UT time signals persist for some some
> subsystems of some planes and ships from some countries under some
> circumstances? A lack of imagination of how this might occur is no
> protection - only an inventory similar to, but perhaps even more
> invasive than, Y2K will suffice.
I'll point out here that Loran-C broadcasts signals based on a 1958
epoch that have no leap seconds. Loran time has diverged from UTC by
23 seconds, since it followed the 'rubber seconds' until 1972, but
used pure atomic time since then that when leap seconds were
introduced. LORAN-C, for those that don't know, is the terrestial
nagivation system used these days as a backup to GPS.
Remember, navigation depends on the solar time only when celestial
sightings are used. Otherwise, it depends on whatever beacons or
signals that are used.
> Second risk - a later change to fundamental assumptions made during
> the design of a complicated system often reveals contingent errors in
> components that depend on those assumptions. We have the issue of
> DUT1 exceeding 0.9s, of course, but other algorithmic assumptions may
> have been made. For instance, use of UTC for calculating intervals
> requires a table of leap seconds. We're given to understand that
> this is subject to error. Those errors are as likely to be revealed
> by the absence of leap seconds as by their continued presence.
> Simply introducing interval time doesn't guarantee that interval
> calculations are bug free.
Given the actual, real implementation experiences of those in the
group that have deal with iterval time, we can be pretty sure that the
number of interval calculation errors will decrease.
> Third risk - UT or GMT permit the use of simple closed form
> algorithms for converting between local and standard, mean and
> apparent time (for example). This is precisely the area of
> remediation that will cause astronomers to incur significant costs -
> we would have to add DUT1 corrections to our many assorted systems.
> Navigation applications face similar remediation - even if only for
> backup systems in the case of a GPS outage. Will all airlines, all
> shipping companies, all air and seaports, all national and
> international air and sea traffic control systems, all communications
> channels carry out this remediation - and carry it out perfectly?
> Won't the DUT1 term be added in some instances where it should have
> been subtracted? Such an error might only be revealed years later
> when DUT1 passes some threshold. The phrase "ticking time bomb"
> comes to mind.
In the case of a GPS outage, LORAN-C is used. It is specifically
still maintained, at least in the US, as a backup in case something
bad happened to GPS system (most likely the ground station). There's
a new data channel for LORAN-C which just went operational that
propigates backup information as well. If you need to go to a
tertiary backup, assuming that the new Galileo system also goes out,
you're unlikely to have the necessary charts at hand anyway. They are
bulky and take up a lot of space, relatively speaking. And they tend
to be specific for a given location (which is what makes them bulky).
> Fourth risk - sabotage, or simply stale data structures. NT will
> often need to be corrected using DUT1. Values for DUT1 change and
> must be maintained in some tabular data structure. That table must
> be loaded with some cadence using some strategy - perhaps the values
> are downloaded when needed from the internet - perhaps they are
> preloaded into firmware. In either case, the values may be incorrect
> due to either intentional or unintentional mischief. The behavior of
> two otherwise similar systems may diverge simply because their data
> structures or strategies for updating these differ.
This is no different than the leap second tables today. If you don't
know the number of leap seconds, you can't recover time from GPS or
LORAN-C signals. However, you do not need to know DUT1 values to get
highly accurate results from both of these navigation systems.
> Ignore all of the many other misadventures that could result from
> clock errors - do I really need to spell out the possibility of
> midair or sea collisions from any of these risks? A primary, well
> tested, system goes out for some obscure radio beacon, for instance.
> The secondary system has a bug whose genesis is risk 1, 2, 3 or 4. A
> plane from one airline uses that beacon - another airline's aircraft
> is flying a parallel track in the opposite direction (as I am assured
> they do to high precision) but is guided by a different navigation
> system without the same bug. Their intended paths never cross, their
> actual paths do. Or an oil tanker runs aground, or an owner piloted
> sailboat misses landfall in the middle of the Pacific, or...
Yes. There are risks.
> Even the most well-conceived and carefully planned incremental change
> to civil timekeeping might require a deployment schedule allowing for
> very lengthy stages of remediation and testing. But in this case a
> dramatic change is proposed to the core philosophy of timekeeping -
> we would be moving from a phenomenologically coherent situation (mean
> solar time kept up to date via small corrections) - to an even
> interval time scale in which any conversion to Earth orientation
> would have to be introduced explicitly.
>
> Leap seconds are asserted to be a risk. Does their lack present
> fewer risks? Prove it.
No, you prove it. Such rhetorical devices are designed to divide and
separate, rather than to understand the problems at hand.
Warner
Received on Wed Jan 25 2006 - 10:31:50 PST
This archive was generated by hypermail 2.3.0
: Sat Sep 04 2010 - 09:44:55 PDT