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

In the case of calendar events, you may also want to be able to express
an event as a starting time/date and a duration.

I think the important thing is to be able to capture what the human
intended when they create the calendar entry. In particular, consider
the case that happened a couple of years ago when congress changed the
definition of America/New_York. If calendar events had been normalized
into some specific timezone, then they would all have been wrong after
the definition change. If I say that I want to be woken up by playing
the radio 07:00 each weekday in America/New_York timezone for 45
minutes, then that should be what the entry reflects. Converting this
into (almost) any other form loses the originator's intention, and will
only lead to problems in the future. [Do you think that Congress will
never mess with DST again?]

Philip

On 25-Mar-10 16:13, Suresh Chitturi wrote:
> 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.
>
>   

-- 
Philip Gladstone
Distinguished Engineer
Product Development
pgladstone@cisco.com
Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
Google: +1 978 800 1010
Ham radio: N1DQ

Cisco.com - http://www.cisco.com

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html