Welcome to the NavList Message Boards.


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

Compose Your Message

Add Images & Files
    Re: NIST website time accuracy
    From: Gary LaPook
    Date: 2010 Aug 05, 10:40 +0200

    I now have three clocks running on my computer, NIST (
    http://nist.time.gov/timezone.cgi?Pacific/d/-8/java# ), Navy celnav
    website (
    ) and the USNO time website that you pointed out (
    http://www.usno.navy.mil/USNO/time/display-clocks/simpletime )
     When I refresh both of the Navy clocks they start off one second behind
    NIST and drift slower. The celnav website updates every 5 minutes but
    always starts one second behind NIST. The USNO website updates every 3
    minutes and also starts one second behind NIST. The two Navy sites stay
    in lockstep but there may me a several second difference between them
    depending how much the first site has drifted when the the second site
    updates. After an hour I noticed that the NIST time had advanced a
    second compared to my watch which I am sure did not loose a second
    during that period. I refreshed the NIST site and it now agrees with my
    So, who do you trust?
    I am only looking at this to make sure my watch is set properly which I
    usually use WWV to do but I can't receive that here in Europe.
    Frank Reed wrote:
    > Gary, you wrote:
    > "it displays the time from the USNO master clock. If you also have
    > open the NIST site you can compare the two times. When you first go
    > the the Navy site the two times are in agreement but after a short
    > while the USNO master clock time runs slow, it is 39 seconds slow
    > right now on my computer. If I refresh the Navy site the time is again
    > in synchronization.
    > Curiouser and curiouser."
    > The time display on the USNO site uses a simple bit of javascript to
    > display the time. It also, most likely, does not do any of the tricks
    > like checking round-trip travel time or using UDP which, I think, are
    > employed in the java app that you see on the NIST site (despite the
    > similarity in name, javascript and java are radically different things).
    > So why does the USNO clock fall behind? Probably because the coder of
    > that javascript tool made a common error (also known as a "less than
    > optimal design choice") in creating the clock display on this specific
    > web page. There are coding objects usually called "timers." They are
    > used in most applications like this that have to update themselves on
    > a regular basis. For example, you can set up a timer to "fire" once
    > every second to update a display. When this occurs with a clock
    > application, you have two choices: take the previously known time and
    > add one second to it, OR you can read the system clock (your
    > computer's clock in other words) and add to that some offset in
    > seconds which was generated when the software first polled the really
    > accurate online source. Those might sound like they would yield
    > identical results, but the first depends on those timer events
    > occurring at exact one second intervals. But they don't do that. A
    > software clock programmed to update that way will drift rather
    > quickly. Instead you have to rely on the local built-in clock to get
    > some time with an error determined on launch. A third approach would
    > be to re-poll the accurate online source at some short interval, maybe
    > once a minute. I suspect that the USNO javascript on that web page
    > does this eventually but the interval may be over an hour.
    > Update since I wrote the above: I've just discovered another USNO
    > online clock, probably implemented by a different programmer or maybe
    > by the same folks a few years later, that does exactly this third
    > option. It's located here:
    > http://www.usno.navy.mil/USNO/time/display-clocks/simpletime
    > and it re-polls the exact time once every three minutes thus avoiding
    > the drift problem.
    > With modern GPS-equipped smartphones and similar small computers,
    > there's still another option. It's possible to write applications (and
    > they do exist) which request the GPS fix time from the GPS hardware
    > along with the position data. That can then be displayed with an
    > accuracy of some small fraction of a second depending on the
    > processing time of the code. I've experimented with this on an Android
    > phone (Android is an operating system developed primarily by Google
    > and used on huge numbers of new smartphones ...as Windows is to
    > Macintosh, Android is to iPhone). The standard system time displayed
    > through the usual clock applications on these devices is accurate to
    > about 15 seconds which is good enough for most phone users, but you
    > can bypass that close-enough time and get at the more accurate GPS
    > time using various freely-available apps. The same should be true on
    > iPhones and other iOS devices, but I haven't actually yet.
    > -FER
    > ----------------------------------------------------------------
    > NavList message boards and member settings: www.fer3.com/NavList
    > Members may optionally receive posts by email.
    > To cancel email delivery, send a message to NoMail[at]fer3.com
    > ----------------------------------------------------------------

    Browse Files

    Drop Files


    What is NavList?

    Join NavList

    (please, no nicknames or handles)
    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 Settings

    Posting Code:

    Custom Index

    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