Welcome to the NavList Message Boards.

NavList:

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

Compose Your Message

Message:αβγ
Message:abc
Add Images & Files
    or...
       
    Reply
    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.
    
    
    
    

       
    Reply
    Browse Files

    Drop Files

    NavList

    What is NavList?

    Join NavList

    Name:
    (please, no nicknames or handles)
    Email:
    Do you want to receive all group messages by email?
    Yes No

    You can also join by posting. Your first on-topic post automatically makes you a member.

    Posting Code

    Enter the email address associated with your NavList messages. Your posting code will be emailed to you immediately.
    Email:

    Email Settings

    Posting Code:

    Custom Index

    Subject:
    Author:
    Start date: (yyyymm dd)
    End date: (yyyymm dd)

    Visit this site
    Visit this site
    Visit this site
    Visit this site
    Visit this site
    Visit this site