views:

1290

answers:

5

I've been asked to display the 'correct' time on our website which I frankly feel is rather pointless as 'correct' can be interpretted in such a variety of ways.

Our current method definately results in an inaccurate time as it uses a server control rendering JavaScript that runs onload using the datetime from the server as a parameter to create a clock object in JavaScript that finally renders on the page and then starts incrementing the clock. Between the server processing, network latency and client-side performance (there's plenty other stuff running onload) the clock ends up way off the actual server time and who knows compared to the client PC.

So to get the 'correct' time shown I could;

  • Use local PC time and pass new Date() to the JavaScript clock object. Pros: Should be as close to the PC clock as possible. Cons: Not sure how accurate the PC clock is let alone in which timezone.
  • Use web service for TCP request to NTP server to update clock on web page. Pros: If local PC also sync'd to NTP will be accurate and best possible match. Cons: Will have to handle all the timezone adjustments relative to our servers. If PC clock is out will still have mismatch.

Do I implement my own web service or use something like; Earth Tools or World Time Web Service (EDIT: link removed - now 404)

Here's a blog post from Jon Galloway on Atomic Clock Web Service which is pretty old and yet ranks high when I google and he doesn't reach a conclusion.

Hoepfully I can win the argument with management why syncing to our server clock (GMT) doesn't makes sense if your not in that timezone and why we even need to match a local PC.

Any angles on this I'm missing?

A: 

you can use geo targeting to know the physical location of a website visitor and in your database stored the (GMT - XX:XX) of the zone and then calculate the time based on the location of the request. that is going to save the long trip to any third party web service.

Oscar Cabrero
Oscar makes an important point in a non-obvious way: there are non-integer hour offsets for some time zones. I think they are all increments of 30 minutes, except for a few that are really elaborate jokes. Check that though.
rmeador
+1  A: 

First, be certain that your client is aware that Windows, Linux, and OSX all have built-in clocks that are almost always visible to the users (or made visible very easily). Also, be certain that your client is aware of physical clocks that are often located near any kiosks that might be setup to hide the built in clock from the operating system.

If you know that, and your client still wants a clock on your website, have your client define "correct" time, then implement the solution that matches their definition (both of your solutions seem like they would take care of the two most-likely definitions).

Illandril
A: 

Another way you can implement it is using IP Geolocation. There are services that can tell you where your user is connecting from based on it's ip (usually including their timezone) and combining that information with your server's realtime clock you can show the user it's local time.

It's far from perfect, specially with corporate users that might seem to be connecting from somewhere they are not (I live in Argentina, but my work internet connection is trough my employeer that is an American company, so every website assumes I'm located in the US)

Ricardo Reyes
+2  A: 

I needed to show the accurate time to clients in an auction web app. You can send the current server time with the page and have the javascript initialize right away without waiting for the rest of the page to load. So the, you only are dealing with network latency which in the worst case is not likely to be more than a couple of seconds.

After that, you're pretty darn close to accurate time. As long as your Javascript timer code is written properly, you're not going to far out of sync before the next page load. But I have seen a lot of bad JS clock code. (Hint: Date() good, setTimeout() bad.)

If you have an application that users are going to be sitting on for a long time, just refresh your time sync either by reloading the page or Ajax.

I wouldn't worry about time zones, just use UTC time so there is no confusion about what time things will happen.

Sal
"network latency which in the worst case is not likely to be more than a couple of seconds" - a couple of seconds was really acceptable in your action web app?
bzlm
It's not ideal, but any network application will have to deal with latency. What was important for the auction was that we were careful about preventing race conditions or posts received after the closing time according to the server's clock.
Sal
A: 

Handle time in UTC.

  • Have users tell you what zone they want to use.
  • If your users have persistent profiles, persist the choice.
  • Always display UTC and Local Time side by side and clearly labelled.

You can also display an arbitrary number of user specified zone clocks. Vista does this and I remain surprised at how handy it is.

Peter Wone