RE: ACTION-129: Expressing timezones in the Calendar API

Le lundi 29 mars 2010 à 16:10 +0200, richard.tibbett@orange-ftgroup.com
a écrit :
> > I'm still not quite sure why you don't want to extend the 
> > ECMA Date object (which would avoid having the developer 
> > converting between one and the other).
>
> Assuming a TimezonedDate object would need a constructor (as per ECMA DatE) I enter the following:
> 
> new TimezonedDate(new Date(), 'America/New_York');

I was more thinking of new TimezonedDate(year, month, day, hour, min,
sec, timezone) (since the constructor presumably needs to extend the
Date() constructor).

> Proposed Output (based on e.g. UTC+1 system time of 15:30:00):
> >> Mon Mar 29 2010 09:30:00 GMT+0100

Hmm... It seems to me that the output is the very last thing we need to
worry about? My guess would be that
        new TimezonedDate(2010,03,29,9,30,0,"America/New_York"); 
would lead to a string representation of
        Mon Mar 29 2010 09:30:00 GMT-0400
(and that the nitty-gritty details of converting the timezone name to
the UTF offset would be dealt with by the browser, not the developer)

> If the ECMA Date object were used, all implementations would need to
> be timezone aware - which means they will need to have a constantly
> up-to-date source for timezone information (as timezones can and do
> change often and without pattern all across the world).

Well, I don't think browsers can provide a calendaring API without
relying an up-to-date source of timezone informations (the same way most
calendaring applications need to update their database of timezone
information every so often, with varying degrees of success).

> You suggested overriding the Stringifies functionality of the ECMA
> Date object. The implementation required to produce a TimezonedDate
> interface becomes complex quickly (e.g. I tried in JS and failed -
> though it is perhaps possible).

I agree this is complex; that's why I think leaving it to the browser
developers is probably the best approach :)

> Having said that there are always workarounds and it is not entirely
> implausible to use ECMA Date, just that in the spirit of keeping in
> simple, being agnostic to timezones in the API whilst still providing
> the information required to reconstruct timezone-bound and
> non-timezone-bound date objects on retrieval might be easier to
> implement initially.

I think your approach has clearly the benefits of being more simple, but
with a non-negligible cost for developers - they will have to convert
between that structure and ECMA Date each time they want to use a
function that relies on ECMA date. Maybe this is the kind of cost that
JavaScript frameworks can absorb, but it still feels not very pretty to
me; given that pretty much any development out there has a
timezone-aware date interface, I don't think we would do a bad thing to
the world by adding that to JavaScript, while maintaining compatibility
with the existing interface.

Dom

Received on Monday, 29 March 2010 15:50:22 UTC