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

----------
|        |   Rich Tibbett
|        |   Orange Labs UK :: Service Evolution :: Research Engineer
| orange |   T: +442088495885 M: +447973525063
----------   

"If we knew what it was we were doing, it would not be called research, would it?" - A Einstein
 

> -----Original Message-----
> From: Dominique Hazael-Massieux [mailto:dom@w3.org] 
> Sent: 29 March 2010 11:15
> To: TIBBETT Richard RD-ILAB-LON
> Cc: andrew@morphoss.com; pgladstone@cisco.com; 
> public-device-apis@w3.org
> Subject: RE: ACTION-129: Expressing timezones in the Calendar API
> 
> Le vendredi 26 mars 2010 à 18:25 +0100,
> richard.tibbett@orange-ftgroup.com a écrit :
> > I agree, though I don't have any formal liason with ECMA. 
> Can another 
> > member of our group (or the group itself) ask for feedback 
> on option 2 
> > from ECMA??
> 
> I think writing a message on the topic to 
> public-script-coord@w3.org is probably the best first step - 
> that's where the informal coordination with ECMA TC39 is done at W3C.
> 
> > The proposal here is to only store and communicate the 
> properties that 
> > are required to reconstruct a date and time object on any given 
> > platform without getting in to the gritty details of timezone 
> > reconstruction ourselves in the spec. We also side-step the issues 
> > with the ECMA Date object (though the parameters provided 
> can be used 
> > by a developer to construct an ECMA Date object if desired).
> 
> 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');

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

Two assumptions have been already made:

- The user must know their current system offset from UTC
- The user must know the time difference between America/New_York and UTC.

The use case was that the 'event' finishes at 15:30 New York Time so how would I set this time without the two assumptions above? (the TimezonedDate object returned 09:30 instead)

Add to this the inability to a.) remove and b.) set/reset the timezone on the ECMA Date object itself which makes "floating times" impossible without continual adjustment according to the user's current system timezone and timezone-based times difficult without constant adjustment to the calculated Date object.

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).

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).

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. The simple DOMString-attributes approach I proposed is also suitable for db-based storage rather than having to store ECMA objects directly in a database something which is fairly bad practice in most programming environments.

Always interested in further thoughts, and there is a lot of more complex issues, but those are the main ones I came across.

- Richard

Received on Monday, 29 March 2010 14:11:04 UTC