My buddy (and fellow Chicagoan) Justin gave me a heads-up about chicagotribune.com's baseball strike real-time countdown timer. It's on the site's home page, about halfway down, in a sidebar on the left side of the "Business | Technology" section. This is what it looks like:
However, as nifty as this feature is, I'd like to point out a mistake under the hood that ends up giving some users inaccurate information.
Try it yourself. Here's how to change your clock: Windows / Mac / Mac OS X / Linux. For a good time, change your computer's clock to the year 2000.
See the problem? The Chicago Tribune's site is putting itself in a hazardous position by assuming users' clocks are correctly set. This results in journalism that's flat-out incorrect if users' clocks are incorrect. (From my experience, many are. But even if 99 percent of computers did have correct date and time settings, that remaining 1 percent would still get inaccurate information -- and that's unacceptable.) This is just as bad as misspelling a source's name or reporting a factual error. Don't think that just because this is the Web, journalistic principles can be compromised.
In short, I guess the lesson here is: Relying on client-side information to produce content that aims to be journalistically sound is a bad idea.
First, we need to determine the offset between the correct (server) time and the user's computer time:
// Get correct time from server
var correcttime = new Date("<!--SERVER TIME-->");
// Get user's computer time
var systemtime = new Date();
// Calculate offset between the two
var offset = correcttime.getTime()-systemtime.getTime();
<--SERVER TIME--> should be replaced with whatever server-side date-generating code is available. Simple server-side includes will do the trick.
Then, use the offset each time the recursive
showtime() function runs. Instead of
today = new Date();, we'll use
today = new Date(today.getTime() + offset); That's it.
I should mention that this will cause a delay of several seconds between the time the page is requested and the time the page is loaded fully (and the onload method begins). But, I believe a margin of error of a few seconds is allowable.
Posted by topjmy on June 29, 2003, at 3:15 p.m.:
A time zone independent countdown timer is exactly what my virtual fighter squadron is looking for to facilitate coordinated meets. Since we are geographically dispersed, and rules for time zones differ between regions, we've been less than successful getting everyone online at the same hour. I'd like to put a bit of code like this in our site, so no matter whether you're logging in from Australia or Austin, Texas, you get the same days, hours, and minutes until the next meet
Posted by Owen Blacker on December 3, 2003, at 12:49 p.m.:
topjmy: you could always just calculate everything using UTC, if that's all you need, as well. Date.getUTCHours() will give you the same as Date.getHours(), but without the clientside timezone offset.
Though setting everything with server time, which you know should be correctly set (one would hope) would still certainly be useful... :o)
Posted by Varun on June 30, 2004, at 5:27 a.m.:
But wont your script have the same problem as theirs? Since you are reading the client side time and thus calculating the offset, if its wrong, everything goes awry!
The better thing would be to let the date be entered into the script and the difference be calculated between the server time and entered date and that shown as a countdown.
Now theory is rather nice but if i only knew how to code it!
Can you help? or direct to an example where this has been done?
Comments have been turned off for this page.