The answer to your question is GPS devices. They're supposed to take into account (most of) what you mentioned, and even though consumer GPS devices are fairly cheap and not up to industrial or even military GPS, time is one thing they do right. In fact, for several projects that needed a reliable time source instead of using the (as you noticed) poorly implemented atomic clock radio frequencies, we would just buy GPS chips to just extract the time signal.

<removed NTP stuff>

I simply don't have any clocks that aren't part of electronic devices, my wristwatch being the exception (but it's analog (Roman numerals, even :P) and only has second accuracy anyway, so I don't fuss about it).

Simply put, all my devices take care of all this for me. My MacBook and Windows 7 work desktop are both configured to sync to the Apple NTP servers (lowest ping for me, AND they're always up. Microsoft's are down a good 10% of the time in my experience). My cell phone gets its signal from God knows where (iPhone 4S - it could technically be using one of 4 different sources) but is always more or less in sync with the rest (I just checked with time.is for what little that is worth, however, and while my MacBook says that my time is within the margin of error "The difference from Time.is was -0.007 seconds (±0.018 seconds).", my iPhone returns "Your clock is 0.5 seconds slow" - but I would trust my iPhone's NTP implementation over time.is' response as its the same OS X NTP that got it "right" on my MacBook) as it can theoretically use a) GPS b) GSM/CDMA towers c) NTP d) time from PC sync.

All my other electronic devices fall in the same category. Garmin nüvi (GPS), Kindle (NTP, auto configured), Cisco IP Phone (NTP, manually configured), Brother printer (NTP, manually configured). I purposely do not set my microwave clock because a) I'll never get it right, and b) any time the power cuts, it resets and in 2012 they're still too stupid to add a 5 cent battery to keep the time in case of power outage.

NTP does a lot more than what you theorized about and none of it is trivial.

FYI: Ping is a remarkably bad tool to gauge the accuracy of remote time source. What is the delay value from "ntpq -p"

I highly doubt that Apple's time servers are your best bet for time synch. Use the pool.ntp.org servers, preferabbly with your country code: e.g. us.pool.ntp.org, ca.pool.ntp.org.

I removed the bit about NTP as it was mostly half-baked ramblings. I obviously didn't mean "ping" the tool, rather the process of "pinging" a remote address and gauging the response time, at the most basic.

My ntpq -p output:

        remote           refid      st t when poll reach   delay   offset  jitter
   ==============================================================================
    time.apple.com  .INIT.          16 u    -  512    0    0.000    0.000   0.000

Your computer has not successfully contacted the time.apple.com server. If it had the refid would not be INIT and your "reach" value would not be 0.

what happens if you change your time server to us.pool.ntp.org? (Substitute your country code for "us".)

Preferably you should have more than one server. The ntp reference implementation on osx is a little goofy because of the GUI configuration. But I think if you put us.pool.ntp.org,us.pool.ntp.org,us.pool.ntp.org for the server your computer will try to spin up three ntp connections. Atleast three, never two...

"A man with one watch knows what time it is; a man with two watches is never quite sure."

> But I think if you put us.pool.ntp.org,us.pool.ntp.org,us.pool.ntp.org for the server your computer will try to spin up three ntp connections.

Close, but not quite; ntpd appears to be smart enough to realize you have three identical "server" lines in ntp.conf, and collapses them. Try this instead:

1.us.pool.ntp.org,2.us.pool.ntp.org,3.us.pool.ntp.org

Changing "us" to your country code, of course. Just tested, and it appears to produce the desired behavior.

ntp is not "smart enough to realize you have three identical "server" lines in ntp.conf". Before the addition of the pool directive in 4.2.7 this was the recommended approach (as in recommended by prof. mills, harlan and the rest of the ntp reference implementation team). OSX is trying to be cute and thinks it knows more about ntp than the user.

Try editing /private/etc/ntp.conf and append:

  # use multiple ntp servers
  server us.pool.ntp.org iburst
  server us.pool.ntp.org iburst
  server us.pool.ntp.org iburst

Make sure you have an extra empty line above the comment. There is something goofy about the way osx includes the input from the graphical configuration and what is included in the /private/etc/ntp.conf In order to restart the service you need to disable/re-enable the automatically set time.

Radio controlled clocks are subject to numerous sources of error. However two seconds is pretty bad, according to NIST the RCC "should always be accurate to within one second of UTC, assuming that they synchronize at least every other day and that their quartz oscillator is of reasonable quality." How far do you live from Fort Collins, CO? I have included some WWVB references at the end...

My GPS + Pulse Per Second fed ntp server is remarkably better than a radio controlled clock. The Sure GPS evaluation board probably costs less than your radio controlled clock:)

  dfc@ronin:~$ ntpq -p 
       remote           refid      st t when poll reach   delay   offset  jitter
  ==============================================================================
  oGPS_NMEA(0)     .GPS.            0 l   12   16  377    0.000    0.001   0.001
   bonehed.lcs.mit .CDMA.           1 u   32   64  377   51.365    0.670   0.364
   rooster.stonybr .CDMA.           1 u   14   64  377   49.019    6.141   0.445
   navobs1.oar.net .USNO.           1 u    1   64  377   57.310    9.494   0.456
   meg.ee.lbl.gov  .PPS.            1 u    1   64  377   88.639   -2.204   0.270
  dfc@ronin:~$ ntptime
  ntp_gettime() returns code 0 (OK)
    time d3076554.79d48450  Sun, Mar 11 2012 13:54:28.475, (.475899416),
    maximum error 234 us, estimated error 0 us, TAI offset 34
  ntp_adjtime() returns code 0 (OK)
    modes 0x0 (),
    offset 0.856 us, frequency -32.941 ppm, interval 1 s,
    maximum error 234 us, estimated error 0 us,
    status 0x2001 (PLL,NANO),
    time constant 4, precision 0.001 us, tolerance 500 ppm,

Radio clock reference material:

NIST Page on Radio clocks: http://www.nist.gov/pml/div688/grp40/radioclocks.cfm

"How accurate is a radio controlled clock" http://tf.nist.gov/general/pdf/2429.pdf

"WWVB Radio Controlled Clocks: Recommended Practices for Manufacturers and Consumers": http://tf.nist.gov/timefreq/general/pdf/2422.pdf.

>"physical atomic clock"

Are you trolling or did you really miss the whole phrase "physical atomic clock synced clocks?"

I apologize. I will edit my post. I did not see the synched the originally and/or his post was edited.

When I was a kid, my dad would always set our clocks by tuning the radio to one of the atomic clock broadcasts from Fort Collins. This might be the same source as your automatically synchronized clocks, but the advantage is that it's human-listenable, and not going through any computer networks or algorithms between Colorado and you.

https://en.wikipedia.org/wiki/Radio_clock#List_of_radio_time...

"The advantage is that it's human-listenable, and not going through any computer networks or algorithms between Colorado and you." That is an advantage?

The Fort Collins signal is awful in the northeast. If you want to deal with the disadvantages of not using advanced computer algorithms to govern your clock i would recommend the USNO's phone service:

Time Voice Announcer, Washington, DC: 202-762-1401 & 202-762-1069 (DSN 762-1401, 762-1069)

Time Voice Announcer, Colorado Springs, CO: 719-567-6742 (DSN 560-6742)

Same here. My Dad is a life-long ham radio operator and if I hear a WWV broadcast now, it takes me back to my childhood in a flash.

On a related note, I always liked the British time announcements that used three tones, with the designated time being "at the third stroke". It's like a music conductor conducting a measure before you start playing or singing. I wonder if it's measurably more accurate than just playing a tone with the proper time is reached.

In order to achieve the highest possible accuracy, you have to bring in your own hardware. We use appliances with internal rubidium oscillator clocks which also synchronize with the signal from all visible GPS satellites. This is as good as one can get if you really want to ensure proper time without having an external dependence on a third party or network.

edit: A paper from 1989 on the subject: http://tycho.usno.navy.mil/ptti/1989/Vol%2021_14.pdf

But you are relying on a third party / network. Your rubidium clock is only good for accurately measuring the length of a second. It has no idea when a UTC second begins. You are relying on GPS time in order to know when the UTC begins.

You need time and frequency for "proper time."

You can measure the angle of the sun to sync with UTC. I believe you can get within seconds using commodity equipment.

Without relying on a third party for an accurate GPS fix on your location?

MY understanding of the issue confirms that you would basically need a js implementation of ntp in order for any of this to work.

That's why I laughed when Time.is tried to tell me that my clock was off by 1.8 seconds. Barring the sentence above, it just has no way of determining that.

All things considered it is not such a bad estimate of the time. It looks like it makes it queries the local clock three times to get an estimation of the clock deltas and network delay . Why do you think 1.8 seconds is wrong? What is your ntpq billboard?

*inspects the page

Yeah, you're right. That's not so bad.

It just seemed like it was claiming a lot of precision that, from my own experience of javascript, browsers and network latency, seemed a bit over the top. (Granted, on the order of magnitude of seconds, I'll accept that. Less than 100 ms and I grow suspicious).

what does your machine say for "ntpq -p" and "ntptime"?

Time.gov is slow and ugly and doesn't work on my phone. Fuck time.gov.

Have you tried the naval observatory master clock at http://tycho.usno.navy.mil/simpletime.html ?

Nice find. Thanks.