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

On further analysis it seems the default ECMA Date object isn't going to
cut it for a Calendar API. I remember why it isn't included in the
current Calendar API specification :-)

Running the following script in any browser provides system-specific
timezone information (which is likely incongruous with the addition of
the 'tz' attribute):

<script type="application/javascript">
var d = new Date();
alert(d);
</script>

My Output >> Thu Mar 25 2010 11:24:19 GMT+0000 (GMT Standard Time)

There is no way to manually override the timezone of this ECMA Date
object and this is likely to cause issues to developers and implementors
- if the 'tz' attribute is actually 'Pacific/Pago_Pago' but I'm creating
the event from e.g. Europe then these objects conflict in their
information.

What we need is date and time information without any timezone
implications associated with it - so we can apply any timezone value to
any simple date/time object.

So I see 4 options:

1. define a custom W3C 'Date' interface with no timezoned info (or Olson
Timezone Identifiers only in this W3C Date interface). 
2. define a way remove (or set) the timezone on an ECMA Date object.
3. include wording in the spec to say that all timezone information
derived on an ECMA Date in a TimezonedDate object must be ignored. (this
is probably only going to confuse developers further and is likely not
worth considering)
4. revert to the existing format used in the Calendar API spec for
'Date' objects e.g. 2010-03-25T11:24:19 - thereby removing dependence on
the ECMA Date interface.

Any preferences on the above options? I would suggest option 1 is where
we want to go (though we're getting in to ECMA standards territory and
I'd personally prefer them to take up option 2 if possible).

Any thoughts?

- Richard


> -----Original Message-----
> From: public-device-apis-request@w3.org 
> [mailto:public-device-apis-request@w3.org] On Behalf Of 
> richard.tibbett@orange-ftgroup.com
> Sent: 25 March 2010 10:45
> To: pgladstone@cisco.com; public-device-apis@w3.org
> Cc: public-device-apis@w3.org
> Subject: RE: ACTION-129: Expressing timezones in the Calendar API
> 
> Hi Dom, Philip,
> 
> On 24-Mar-10 21:37, Philip Gladstone wrote:
> > 
> > On 24-Mar-10 11:00, Dominique Hazael-Massieux wrote:
> > >
> > > Thanks for looking into this! 2 comments:
> > > - I think we should choose either the Olson identifier, 
> or the URI 
> > > one, but not mix them both up in a single field; I would 
> personally 
> > > suggest using the Olson identifier for v1
> > > - I'm slightly uncomfortable with binding the whole event to a 
> > > timezone rather than to the specific dates that are defined in it 
> > > (start, end, reminders, and recurrence limits); use cases
> > that require
> > > binding to the dates rather than events are somewhat
> > convoluted, but
> > > it seems like bad design to separate a datetime from its
> > timezone in
> > > general. Also, since we mentioned other cases where we 
> would need a 
> > > "timezoned" datetime (e.g. reception times for messages), I still 
> > > think we should work on TimezoneDate object rather than
> > adding this on
> > > the side for events
> >  
> > There are certainly calendar events that make sense with differing 
> > starting and ending timezones. For example, United
> > 177 leaves Boston at
> > 11:15 America/New_York and arrives in San Francisco at 15:00 
> > America/Los_Angeles -- and this is how the flight will 
> appear in your 
> > reservation. This is the 'obvious' form of the calendar event that 
> > corresponds to my flight.
> > 
> > Thus I support having a timezoned datetime object rather 
> than trying 
> > to split out the timezone into a separate field.
> > 
> 
> Thanks for the feedback and the good use cases.
> 
> Picking up from the previous proposal (Olson timezone 
> identifiers for expressing timezones [1]) we can define a 
> TimezonedDate interface as
> follows:
> 
> [NoInterfaceObject]
> interface TimezonedDate {
> 	attribute Date value;
> 	attribute DOMString? tz;
> }
> 
> The following correction is noted to the 
> CalendarEventProperties interface (superseeds previous 
> example on this thread):
> 
> [NoInterfaceProperties]
> interface CalendarEventProperties {
> 	...
> 	[PutForwards=value]
> 	readonly attribute TimezonedDate start;
> 	[PutForwards=value]
> 	readonly attribute TimezonedDate end;
> 	...
> }
> 
> where:
> 
> - 'tz' can be an Olson timezone identifier [1] (e.g. 'Asia/Seoul')
> 
> If no 'tz' object is provided or 'tz' is null, the 
> TimezonedDate should be considered 'floating' (i.e. 7am 
> regardless of location). If the 'tz'
> value is not a valid/recognized identifier the 'tz' attribute 
> MUST default to 'UTC' (where 'UTC' is a valid Olson Timezone 
> Identifier in [1]).
> 
> PutForwards is implemented on TimezonedDate objects as 
> specified in the WebIDL spec [2].
> 
> 
> 
> I have considered the i18n implications of this approach. 
> IOlson Identifier could map to a Lunar-based implementation 
> of the Olson TZ data. No such database exists currently AFAIK 
> but the abstraction to Olson identifiers may be sufficient 
> for translation to different calendaring systems. Feedback on 
> this is welcome.
> 
> Further on i18n, the TimezonedDate interface definition may 
> wish to include the proposal in [3] for multiple calendar 
> systems support - with the restriction on recurring 
> non-Gregorian events detailed therein still being applicable.
> 
> 
> 
> [1] http://www.w3.org/TR/timezone/#tzinfo
> 
> [2] http://www.w3.org/TR/WebIDL/#PutForwards
> 
> [3]
> http://lists.w3.org/Archives/Public/public-device-apis/2010Mar
/0183.html
> 
> 
> - Richard
> 
> 
> *********************************
> This message and any attachments (the "message") are 
> confidential and intended solely for the addressees. 
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration. 
> France Telecom Group shall not be liable for the message if 
> altered, changed or falsified.
> If you are not the intended addressee of this message, please 
> cancel it immediately and inform the sender.
> ********************************
> 
> 
>

Received on Thursday, 25 March 2010 11:50:12 UTC