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
    Leap second articles in ITU News
    From: Paul Hirose
    Date: 2014 Mar 07, 11:43 -0800

    The September 2013 ITU News magazine has several articles on UTC and the
    future of leap seconds.
    
    https://itunews.itu.int/En/news.aspx?Edition=251
    
    I believe most of the UTC problems described in the articles are really
    due to flawed computer implementations of UTC, not UTC itself. We are
    told that "stopping all clocks in the world for one second in order to
    accommodate a leap second creates an ambiguous hiatus." And there are
    "the problems of time-ordering, causality and the ambiguity of time
    intervals in the vicinity of a leap second".
    
    In reality, UTC doesn't stop when a leap second occurs, and the interval
    (SI seconds) between UTC epochs is not ambiguous. For example, the
    motion of a celestial body during a leap second can be calculated
    precisely. There should be no discontinuity at entry or exit from the
    leap second. To demonstrate, I'll compute the altitude of the Sun at the
    center of a leap second, then use a different program to solve the
    simulated time sight for UTC.
    
    With the JPL HORIZONS program, create a simulated Sun observation at
    2012 June 30 23:59:60.5 UTC from N21.36 W157.96 at sea level. HORIZONS
    says refracted altitude of the center = 70.4349° and diameter = 1887.937″.
    
    Now solve for time with my program Lunar3. Use the JPL DE406 or DE422
    ephemeris. Position = N21.36 W157.96 at sea level. Temperature 10 C,
    altimeter setting 1010 mb. Estimated time = 2012 July 1 00:05 UTC. (To
    make the test more realistic, that's 5 minutes in error.) UT1-UTC = +.41
    second. Enter altitude of Sun center, 70.4349. Select D.d angle format
    and .0001° precision. Check the "solve for time" box and click OK.
    Result: 2012 June 30 23:59:60.41 UTC.
    
    That's inside the leap second, as it should be. The error, -.09 s, is
    due to refraction differences between the programs. They agree exactly
    if you compare unrefracted altitudes at the same time.
    
    It's interesting that the UT1-UTC I gave, +.41 s, was correct for
    the estimated time of the sight, but due to the leap second it was
    really -.59 when the sight occurred. But that did not prevent an
    accurate solution.
    
    I don't mean to imply a time sight is accurate to a tenth of a second.
    My point is that leap seconds don't prevent an accurate, unambigous UTC
    determination from the motion of a celestial body. But it requires
    careful writing of the UTC code.
    
    Regrettably, that was neglected in the design of JPL HORIZONS. It won't
    accept 2012 June 30 23:59:60.5 UTC. To get the simulated observation,
    what I actually did was convert from UTC to the equivalent time in TT,
    2012 July 1 00:01:06.68. A programmer on the JPL staff confirmed my bug
    report, and a fix is in work.
    
    This may be a clue to the reason computers still get messed up by leap
    seconds, even after 40 years of practice. The UTC implementation didn't
    provide for leap seconds, and that part of the program was never tested.
    
    My software is not without sin. If you request a prediction from Tinyac
    at the center of a leap second, the time display in the main window says
    24:00:00.5 instead of 23:59:60.5. However, the position of the body is
    computed correctly. The later Lunar3 program does not have this bug.
    
    Getting back to the ITU news articles, it seems Russia (the Glonass
    people, anyway) and the UK want to keep leap seconds. I don't have any
    guess on what the final decision will be, but everyone who writes
    astronomical software should be ready. If leap seconds go away, even a
    printed perpetual almanac will need modification to its instructions.
    
    --
    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