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 server (Which, in this case is JBoss and Oracle).

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 server (Database or web application tier) 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 context (For us, this happened to be Eastern Standard Time).

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 browsers (Such as Chrome and Fire Fox) will honor timezone designations, other browsers (Such as, surprise surprise, Internet Explorer 6 and 7) doggedly convert any and all Date objects into the timezone  of the current system they are running on (We tested this by simply adjusting the date/time on our Windows desktops).

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.