NavList:

   

Reply

Geoffrey Kolbe wrote:
> Does the Nautical Almanac have to publish its data with reference to 
> UT1? Given today's computer power, it should be a trivial matter to use 
> broadcast time - or any other time system - as the time reference system 
> for its data. An equivalent of DUT could be available in the form of a 
> time correction to keep the ephemerides accurate to their specified 
> precision. Then, for all practical purposes, the status quo would be 
> maintained for practitioners of celestial navigation.

I believe that's the most logical solution if leap seconds cease. UTC, 
or whatever they call it, will become the almanac time scale. The 
replacement for DUT1 could be ∆T (predicted) - ∆T (actual), the 
predicted being the one used to compute the almanac.

For those wondering why ∆T is involved, I should explain that computing 
an almanac entry, such as the GHA and dec. of the Moon, requires the 
time in two different scales. First you compute RA and dec. That step 
involves ephemerides and precession / nutation models, which nowadays 
use TT (Terrestrial Time). Then RA is converted to GHA, which is a 
function of UT1.

UT1 is easy – as the time scale of the tables, it's a "given". To obtain
the corresponding TT, simply add ∆T. Well, actually it's not so simple.
Since the precise value of ∆T is only known after the fact, an almanac 
maker has to rely on a prediction.

I don't know how far in advance the tables are computed. A couple years? 
Fortunately, the predicted ∆T doesn't need to be very accurate. A one 
second error causes only .5" error in the Moon's GHA. Other bodies are 
much less sensitive.

UT1 is more critical. A 1-second error affects GHA by .25'. In other 
words, GHA is 30 times more sensitive to UT1 than TT (for the Moon, the 
body most sensitive to TT). But with UT1 as the almanac time scale, the 
30:1 ratio works in our favor.

This will change if leap seconds cease and the almanac is tabulated in
terms of UTC. In that case, TT becomes the "given" since its offset from 
UTC is constant. Then UT1 is derived from the predicted ∆T. The 
tolerance is pretty tight: less than one second if current accuracy is 
to be maintained.

Of course we already have the DUT1 correction for navigators who need
the utmost accuracy. A similar correction could be issued for error in
the ∆T prediction. Currenty, the sense of DUT1 is such that a positive
number (i.e., UT1 is ahead of UTC) means the actual hour angle of a body 
is greater than the almanac value. If the DUT1 replacement is redefined 
as ∆T (predicted) - ∆T (actual), it would keep the same sense because a 
positive number would mean the prediction had Earth's rotation lagging 
TT by too much. The change would be transparent to navigators who 
already apply the correction.

This "new DUT1" correction is meaningless unless the people who 
determine it agree with the almanac makers on the predicted ∆T. Perhaps 
the IERS could release the predictions as a series
of polynomials, each covering one year. These would be for almanac
computers, not users, so they'd have to be released far enough in
advance to allow for publishing lead time.

That would work for traditional paper and pencil navigators. Electronic 
sight reduction faces different problems. First off, most (all?) legacy 
programs assume the user enters UT1. Internally there's a conversion to 
TT (it may simply be implicit in the formulae), but thanks to that 30:1 
ratio it needn't be very accurate.

For example, according to the ICE program (1989), at Sep 22 0000 UT, 
Moon GHA = 253°54.1', declination = +20°11.8', and ∆T = 74.6 s. An 
independent computation with my own software for 0000 UTC with the 
actual ∆T of 66.5 and actual UT1-UTC of -.3 s gives identical coordinates.

That accuracy won't continue if leap seconds stop and users continue to
enter observation times in UTC as it drifts 5, 10, and more seconds away
from UT1. Eventually navigators with legacy software will have to apply 
DUT1 (in its current meaning of UT1-UTC).

Modern software might allow input of DUT1 so the user wouldn't have to 
add it manually to each UTC observation time. Of course it would be 
possible to include an automatic correction based on a DUT1 prediction – 
basically the same as predicting ∆T minus a constant offset – but the 
prediction model would need periodic updates to maintain accuracy within 
one second.

There may be difficulty getting DUT1 by radio. I understand the proposal 
will also "terminate the requirement that time services transmit the 
difference between UT1 and UTC."
http://futureofutc.org/

Of course ending the requirement doesn't mean the practice has to end. A 
different encoding scheme will have to be developed if they opt to 
continue the double ticks at WWV, though. The current one isn't designed 
for values of several seconds.


Personally, I will be OK whichever way the decision goes. But I wonder 
how many problems will crop up as UT1 drifts away from UTC. For 
instance, consider a precision time distribution system the US NIST 
helped Egypt set up. Only four bits are allocated for the magnitude of 
the UT1-UTC correction, in units of .1 second.
http://tycho.usno.navy.mil/ptti/ptti2007/paper19.pdf

On the other hand, their time code does show how a device can be "armed" 
to automatically insert a leap second. An atomic clock at a place where 
I used to work had a similar feature, but it was manual. A front panel 
switch had to be put in the ARM position, and a second switch set to + 
or - to select a positive or negative leap second. Unfortunately, though 
  several leap seconds occurred in the years I worked there, I never 
managed get to the clock to watch the seconds go 59, 60, 00.

-- 

   

Reply