Timezone pitfalls in AJAX

I just wanted to make a few notes about timezones as you are migrating an existing traditional web application into a more JavaScript heavy application.

We have a mostly traditional web application – RDBMS with POJOs + iBATIS for the data layer, struts for controller, and JSP for presentation. We have inspection objects that include a date and time. This field is entered by the user. There is a timezone associated with the value in our database, but it is somewhat irrelevant as it is not displayed. If you say, 5/1/2007 6:00 PM, it shows 5/1/2007 6:00 PM – no time zone. You can assume it is in your timezone if you want with no harm.

Now, this has some potential problems if you have people sharing data across timezones. For example, this would be unacceptable if you were creating an schedule sharing calendar application if you shared it across timezones. However, it’s not really a problem for us.

Now, as we move the logic out to the browser, we needed a way to pass the date to the server in a JSON object. (The problem of a lack of a Date literal in JSON is lamented here.) The only thing you can do is choose a format and go with it. We chose ISO 8601 because then we wouldn’t need a separate parsing/formatting logic from what we use for our XML dates. What we missed was the fact that this format included the timezone and, now that the date and time were being generated on the client instead of the server, we had the client’s timezone. That was compounded by the fact that all of our testing was being done in our timezone, so the problem was invisible until we went live with the code.

The fix was relatively simple – take the timezone off of our ISO 8601 dates – both when we format it and when we parse it (a last minute fix overlooked one of these). It’s not that it’s such a hairy problem. I only bring it up because it was such an easy mistake to make and an easy bug to miss.