my 2 cents

Dealing with date-time information is a complex topic in any language, as the nature of date-time information is complicated itself. One has to cope with time-zones, daylight-saving-times, and time-shifts, along with dozens of different representations.

Dealing with time-zones in particular is difficult in javascipt, as the language has no build in support for time-zone conversions in it’s Date object.

Javascripts Date object only comes with support for Local Time Zone and UTC. The Local Time Zone is defined by the Host Environment of the javascript interpreter as stated in section 15.9 of the ecma-script specification. But there is no method in the Date object to query or set this Local Time Zone.

This makes date-time computations almost impossible with the build in javascript Date object. As a way out, there a tree scenarios:

1. Try to guess the time zone of the browser. You will find a lot of crap with goolge trying to figure out a time zone by a single time zone offset. I only found a few implementations like discussed here, which try to guess the browser time zone in correctly. The Problem with this approach is, that you would need a huge set of DST data in the client to get reliable results. And even if you know the browsers time zone, you won’t be able to let the user switch time zones, as it’s not possible to set a time zone.
2. Write your own Date object which is time zone capable. This would presumably be the most elegant way for dealing with date-time information in javascript. However such a class would consume much data and computation time and besides having time to write it, i fear that it would have a notable impact on the applications performance.
3. Don’t do any date-time computations in javascript. You may guess the browsers time zone to define it, but the definition itself and all date-time computations must be made in a time-zone aware system. This is the approach we chose for Tine 2.0. PHP 5.2 introduced a great time-zone aware Date class which we use for all related computations.

But even after the judgement not to use the javascript date object for date-time computations there are some difficulties to cope with.

When creating Date objects from the common ISO8601 representation like:
var t = new Date('10/14/2008 22:00:00 +05:00');
the date object substracts the GMT+5 and internally stores the number of milliseconds from 1/1/1970 in UTC to that date. This means actually the information ’10/14/2008 22:00:00 in the users time’ gets lost.
t.toString(), wich is a alias for t.toLocalString() returns:
Tue Oct 14 2008 19:00:00 GMT+0200 (CEST)
in my browser and t.toUTCString() returns:
Tue, 14 Oct 2008 17:00:00 GMT
which is correct, but not what the the protocol communication in the user time zone expects!

To really use the javascript date object as a simple value store, you must make sure to cut the time zone indicator before parsing the date.
new Date('10/14/2008 22:00:00').toString();
returns:
Tue Oct 14 2008 22:00:00 GMT+0200 (CEST)
At least the values are correct. Before sending, or at least on server side you need to cut the offset and time zone of course, as they are obviously crap in this scenario.

Taking all this into account, it’s possible to circumvent the problematic aspects of the javascript date object (we haven’t talked about its DST implementation ) and to deliver a multi time zone capable javascript application.