# NavList:

## A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding

**Re: Dropping leap seconds and the impact on celestial navigation**

**From:**Paul Hirose

**Date:**2011 Sep 29, 17:43 -0700

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. -- I filter out messages with attachments or HTML.