I like Time.gov, personally; it was the first site I ever found around this concept and so it has a soft spot.
I keep finding all my physical atomic clock synced clocks (yes, I have more than one, they are cheap these days) disagreeing, sometimes by 2 seconds or more, which makes me laugh (great ideas ruined by poor implementation). I find many of the web sites (listed in comments or the original post) to also differ, perhaps for similar reasons of implementation choices.
I would presume all the sites work off various implementations of NTP, http://www.ntp.org/ plus some trusted source.
I guess my question is: has anyone found a site which is really, really accurate by reducing all the latency and lag, so what you see on the screen really is, to whatever precision, accurate? And would said person have access to a really good source for the comparison point? I don't seem to have one. Yes, I should have stopped at 3 so that I could pick the 2 closest ones (like the old saying: 1 clock is unsure, 2 clocks are worse, but 3 at least lets you make a decision)
I wonder, would you need to have NTP on the client side synced to a trusted source (say, in java, flash, or javascript) to get a good reading? Any server serving over HTTP induces lag, I would think, and NTP is supposed to account for transmission delays, or so I recall.
Thanks for sharing, another interesting time site to add to the collection.
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:
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.
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.
"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:
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.
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,
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.
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.
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?
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).
A lot of people are making disparaging comments about the acccuracy of the site's time estimation with little or no explanation/data. All things considered (three samples to estimate clock deltas and network delay) the time estimation is fairly accurate.
time.is reports my clock is:
-0.004 seconds (±0.021 seconds).
I have a stratum one time source on the local network (gps+pps) and my ntptime agrees with the time.is estimation:
dfc@bushido:~$ ntptime
ntp_gettime() returns code 0 (OK)
time d3077752.4160a634 Sun, Mar 11 2012 15:11:14.255, (.255381196),
maximum error 260579 us, estimated error 3294 us, TAI offset 34
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset -4842.630 us, frequency 8.446 ppm, interval 1 s,
maximum error 260579 us, estimated error 3294 us,
status 0x6001 (PLL,NANO,MODE),
time constant 10, precision 0.001 us, tolerance 500 ppm,
NB: this is my laptop. so powersaving, heat fluctuations are adding a decent amount of uncertainty from a metrological standpoint.
I'm wondering how atomic clocks in general get set in the first place. Did, at some point, scientists calculate when the sun was exactly overhead Greenwich and call that noon? Because I would think that that calculation would have a multi-second error, so setting your clock to the second would be pointless.
Or maybe there is no such thing as "actual physical time" and there is only what people have agreed to call the standard. But in that case why do time sources, such as time.gov and time.windows.com, still give different times? I would think Microsoft would have fixed any bugs in their NTP implementation by now, so it's not that. If it's just politics about nobody wanting to move to someone else's time, then there's no way to tell which source is the real standard, so your most practical choice is to synchronize your clock to the times you deal with. That is, set your clock to your clock at work, or an average of your friends clocks, or whatever source they get their time from. I don't mind the existence of central time sources, because they are better than having to go out and find someone else's clock, but they shouldn't call themselves official if they aren't actually official.
So, does anybody know how the starting time for central time sources is chosen, and if any source is worthy of being called "the real time"?
"Originally published in 1977, this full-length book provides a comprehensive, easy-to-understand introduction to the field of time and frequency. Readers of nearly all ages and educational backgrounds should find it enjoyable. 306 pages."
Well… it's an arbitrary standard. We just call a day one full rotation of the earth, and we just happen to divide it into 24hr periods with 60 subdivisions.
Theoretically, you could measure the rotation of the earth and call that a day, but I have no idea how you would measure that down to the millisecond.
I too would be interested in how they picked the beginning epoch, i.e. "this moment right here is midnight from which all other seconds shall be referenced against" but in the grand scheme of things it doesn't matter - the only thing that matters is the standard we agreed to measure against.
Except that "…due to nutation, an actual sidereal day is not quite so constant."
Yeah. Nutation.
Nutation "…is a rocking, swaying, or nodding motion in the axis of rotation of a largely axially symmetric object, such as a gyroscope, planet, or bullet in flight…"
You also need to make sure your IANA tzdata is updated to account for this. I think this leap second was first added in tzdata2012a, but I'd have to check:
"Unix time, (...) is (...) defined as the number of seconds elapsed since midnight Coordinated Universal Time (UTC) of Thursday, January 1, 1970 (...) not counting leap seconds"
You might not be able to ignore leap seconds if you are interacting with an external system (software or hardware) / API that expects actual UTC. General rule applies to everything.. know your system, know what systems you are connected to, know what standards you need to adhere to.
Microsoft apparently rejected the idea of using leap seconds because Windows just isn't accurate enough:
The W32Time service uses the Network Time Protocol (NTP) in
Microsoft Windows Server 2003, in Windows Server 2003 R2,
in Windows Server 2008, and in Windows Server 2008 R2.
...
The W32Time service cannot reliably maintain sync time to
the range of 1 to 2 seconds. Such tolerances are outside
the design specification of the W32Time service.
GPS Time is designated as being coincident with UTC
(USNO) at the start date of January 6, 1980 (00 hours).
GPS Time does not count leap seconds, and therefore an
offset exists between UTC (USNO) and GPS Time (at this
date in April 2007: 14 seconds).
Unlike GPS, the GLONASS time scale is not continuous and
must be adjusted for periodic leap seconds. Leap seconds
are applied to all UTC time references as specified by
the International Earth Rotation and Reference System
Service (IERS). Leap seconds are used to keep UTC close
to mean solar time. Mean solar time, based on the spin of
the Earth on its axis, is not uniform and its rate is
gradually changing due to tidal friction and other
factors such as motions of the Earth's fluid core.
Basically, much in the same way that we all despise DST (or date differences between Julian/Gregorian calendars), a certain part of me wants to know, if we humans last on this planet long enough, that our descendants thousands of years from now won't look back and curse at us for being idiots and deviating from celestial time.
For the last few weeks, I've been trying to increase my productivity by getting rid of time tracking. So I decided to hide my computer's clock.
Sometimes, like when I have an appointment, I still need to check what time it is. Googling "time" doesn't always work (I don't know why exactly). So I bookmarked this site [1] but the information density is so high that I need to scan the page in order to get the time.
Time.is works quite well, with useful customization options, though it still carries bits of useless information (like the time zones at the bottom). But the time's font size is big enough to trigger instant focus.
UPDATE: as guptaneil pointed out, clicking the time (or navigating to http://time.is/just) removes all the clutter. Thanks for the tip.
Mainly Win 7. Otherwise Mac OS X. Sometimes Win XP, and very rarely Ubuntu.
But I almost never have a terminal open (and don't have a shortcut for that either) whereas Firefox almost always is. So I'm just 1 click away rather than 4 characters away.
You taught me something though (I highly prefer typing on a keyboard than using a mouse or, worse, a touchpad) and I wish I had to spend more time in a terminal.
Why not? I usually have a terminal open for irc / bc -l / git / checking the headers of pages with curl -I, pinging things, WHOIS lookups, wgetting files, etc etc etc.
Governments are free to change timezone rules at will with no real advance notice. Case-in-point, tzdata2012b was just published a few days ago and already on the tz mailing list Morocco's DST date is changing and Haiti apparently changed as well.
The problem is exacerbated by the fact that most systems rely on OS tzdata instead of shipping it themselves, yet in many places the administration of the OS is separated / walled off from the devs who maintain the apps which actually suffer from the bugs.
I feel bad for users who live in countries whose governments play with DST law on a whim, because they are certainly destined to encounter bugs throughout the Internet because it isn't always reasonable to ask all administrators around the globe to patch all production systems in a matter of a few days.
Nice job on this. I usually use http://everytimezone.com but I like how I can configure this with the zones that matter to me. It would be nice if I could easily use my favorites when doing the Here -> There comparison.
I like it a lot. Easy to remember URL. However the services offered are not so good.
At least there is no RFC 867 and RFC 868 date on port 37 and port 13.
This is deprecated, I know, but rdate is still the easiest way to fix the date on a system which do not require precision. I did run my own minimal daemon on my DSL modem for the various gizmos I have that include busybox (thus rdate) and where recompiling to get a ntp would be overkill. (the right day and the right hour are more than enough)
time.nist.gov removed RFC 867 (port 13) and 868 (port 27) support. time-nw.nist.gov kept it a bit longer, then I used by DSL modem, which went in RMA and so guylhem.org is also down.
I'll try to email the author and offer to give a hand.
I know rdate is awful but when that's all you have and don't feel like crosscompiling for a device which does not even requires a minute of precision, it does the job.
Technical excellence is not always required, and having more choices usually is a good idea.
The handling of internationalization is surprisingly good. Texts, including town names, are almost all shown in the preferred language, and the size variations introduced by the translations are well handled.
I would still prefer to have the option to select the timezone. Sometimes I want to attend some workshops that announce the time in one of the US timezones and its always difficult to do the conversion.
I imagine that the author of the page has some scientific background and therefore feels that it is appropriate to publish the margin of error alongside any estimation.
Simple, but awesome. About two years ago I had the idea (but never implemented) to try and re-make various since use web tools and calculators using modern web technology. Things like interest/mortgage calculators, voltage drop calculators, difference between two dates, etc.
So many of them like Time.gov rely on stuff like Flash or Java, or 1998 style Javascript, which I don't really dig. Definitely a nice little hole there for making something cool.
The clock display is nice but not a killer for me. Here&There time comparison in different time zones is the best I have seen. Full page calendar with multiple months is very simple but works great for me.
This is becomes my favorite site for time/date related stuff.
My little Ubuntu machine is -0.018 seconds (±0.009 seconds).
My MBP is -0.012 seconds (±0.021 seconds).
I recommend you add a percentile score of exactness, along with breakdowns based on platform, and suggestions about what to do if the percentile is disappointing.
I am seeing roughly +/- 0.1s accuracy range on my browser. Can someone please enlighten me on why we cannot reduce this further? I assume this page has <100ms response time, can't they get to a better accuracy range?
A) If you're viewing on your phone, it's mobile optimized
B) If you're viewing it on your desktop, why would you want to go to your phone?
C) Time.is has to be the easiest URL to enter by hand in a device browser. :D
I'm not saying it's very useful, but if you see it on your desktop and want to check it or save it on your phone (to verify the time on your phone/QR-and-web-enabled mobile device, to bookmark it for future reference when on the go, etc), the code might help. I've seen this used better than just on an 'about' page, though.
ntpdate is dead and is discontinued. Use an actual daemon to govern your time source.
I thought redhat installed ntpd or chrony by default. I know chrony is the default for the next fedora release. If you have ntpd/chronyd installed your advice is horrible and not just because you pointed everyone to Virginia Tech's time server.
chronyd is a lot more mindful of battery/power considerations than ntpd. It is an interesting approach to endpoint time synchronization compared to the ntp reference implementation.
Cell network doesnt broadcast time. You can install ntp client, but it needs to run as root, and I wont let anything from the market run as root, and I havent got around to building an ntp client myself...
Tell me I'm not the first to see the irony of a page full of comments debating ntp, GPS and atomic clocks, while there are two interesting front page stories about the value of ambitious goals.
I keep finding all my physical atomic clock synced clocks (yes, I have more than one, they are cheap these days) disagreeing, sometimes by 2 seconds or more, which makes me laugh (great ideas ruined by poor implementation). I find many of the web sites (listed in comments or the original post) to also differ, perhaps for similar reasons of implementation choices.
I would presume all the sites work off various implementations of NTP, http://www.ntp.org/ plus some trusted source.
I guess my question is: has anyone found a site which is really, really accurate by reducing all the latency and lag, so what you see on the screen really is, to whatever precision, accurate? And would said person have access to a really good source for the comparison point? I don't seem to have one. Yes, I should have stopped at 3 so that I could pick the 2 closest ones (like the old saying: 1 clock is unsure, 2 clocks are worse, but 3 at least lets you make a decision)
I wonder, would you need to have NTP on the client side synced to a trusted source (say, in java, flash, or javascript) to get a good reading? Any server serving over HTTP induces lag, I would think, and NTP is supposed to account for transmission delays, or so I recall.
Thanks for sharing, another interesting time site to add to the collection.