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² 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³.

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⁴ will honor timezone designations, other browsers⁵ doggedly convert any and all Date objects into the timezone  of the current system they are running on⁶.

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.

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