Browsers, timezones, and Date


Recently I ran across an interesting problem involving dates and timezones while working on a rich web 2.0 application whose primary purpose was to allow the user to enter time values that were then saved, as true date objects, onto the server1.

Up until now I have not used time values on both a server and client level, I’d referred instead to use a UNIX timestamp that the server2 did not touch or, if they did, they did so with the client being the authoritative source.

This case was different in that the server was the authoritative source and all clients were required to deal with time values in the server’s timezone context3.

Herein lies the rub.

For this project we were using ExtJS 2.2.0 and made extensive use of ExtJS’s extensions to the regular Javascript Date object. Little did we know, the Date object is implemented per browser and while some browsers4 will honor timezone designations, other browsers5 doggedly convert any and all Date objects into the timezone  of the current system they are running on6.

While there are some solutions out there like Freegix that perport to include solutions for switching timezones on the client-side, we have yet to find any solutions that are truly drop-in replacements.

Why couldn’t IE just honor the ‘T’ or ‘O’ designations in the first place? One can only wonder what possessed the IE team when it came to this issue…

So if you are writing a web 2.0 application that passes dates between the client and server, make sure you remember that the browser has the final say in how your time gets parsed.

No related content found.

  1. Which, in this case is JBoss and Oracle []
  2. Database or web application tier []
  3. For us, this happened to be Eastern Standard Time []
  4. Such as Chrome and Fire Fox []
  5. Such as, surprise surprise, Internet Explorer 6 and 7 []
  6. We tested this by simply adjusting the date/time on our Windows desktops []

Leave a comment