strike countdown

Written by Adrian Holovaty on August 24, 2002

My buddy (and fellow Chicagoan) Justin gave me a heads-up about'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:

Screenshot of site, with countdown

This is a really cool, fun, useful and relevant use of JavaScript in a journalistic setting: It's a second-by-second countdown to the baseball players' union's Aug. 30 strike date. Will baseball team owners and the union come to an agreement by then? The clock is ticking -- for all readers to see. It gives the story a real sense of immediacy; plus, it grabs readers' attention more than a plain headline and blurb would.

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.

The problem is, the script depends on information on the user's computer to calculate the countdown time. Specifically, its JavaScript code checks your computer's system clock for the current time, from which it determines the remaining days, hours, minutes and seconds until Aug. 30. So, for example, if your computer's clock is a week slow, the countdown will be seven days longer.

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.

But this countdown timer idea is too good to be abandoned. It can be fixed, with the help of some sneaky coding. Instead of checking the user's computer time, the script should check the time of a resource it knows is always correct -- the server. Client-side JavaScript cannot access server information, so the solution is to insert server code within the JavaScript. Here's how to do that.

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();

Note that <--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.