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

Hi Richard, all,

Wouldn't it be much simpler to go with the Ecma Date object, and expect
the user/web app do the translation if any? Would this be Option 5?

I understand the default value of new Date() returns the current time
(accounting for the daylight savings time based on the device time and
timezone settings. In fact I ran the script below on my browser and it
showed me the current time based on my local time set on my device
including the day light savings adjustment.

On the mobile, it is intuitive for the user to create events based on
the date, time and timezone (note that tz is typically the same for
start and end time). So, having the timezone attribute as part of the
event properties sounds to me with a default value set to "current
device/system timezone information". When the event is actually stored
on the device calendar it gets translated to the local time, and this is
what I expect implementations to do anyway. If all this we are trying to
do is to be able to set start and end dates with different timezones, I
think it is a use case that is seldom used. It should be trivial for the
user or web app to convert this to a single timezone.

Am I missing something?

Regards,
Suresh

 


-----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: Thursday, March 25, 2010 6:47 AM
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

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


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Thursday, 25 March 2010 20:14:33 UTC