NavList:
A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding
From: Frank Reed
Date: 2010 Aug 4, 20:33 -0700
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
----------------------------------------------------------------