Re: ISSUE-7: Gathering requirements [Calendar API]

On Tue, 2009-11-03 at 21:40 +0100, Jere.Kapyaho@nokia.com wrote:
>  
> Hi all,
> 
> when reviewing the calendar section of the DAP requirements document [1] I
> was reminded of a potential issue from an app developer point of view.
> 
> As all WG members and chairs know, time zones can be a PITA. In the context
> of the Calendar API this raises the question of how to pass in times for
> calendar events. Are they:
> 
> 1) local times according to the client device's clock, with timezone
> information;
> 2) instances of Coordinated Universal Time (UTC) [2];
> 3) either of the above, with some powerful magic to do the right
> conversions?
> 
> It would seem like a good idea to pass and store timestamps of calendar
> events stored as UTC, so that they are always unambiguous. The client could
> then apply any local timezone offset to them as necessary. However, there
> exists prior art about iCalendar [3] that recommends timezone information to
> be present always. Based on that, the timezone is needed on input.

The general problem with using UTC times is that you are storing
information in a lossy manner.  If I have a repeating event which
crosses a DST boundary, and the time of the event is stored in UTC, it
will be wrong once I cross that boundary.  For this reason UTC storage
is best restricted to single-instance events, and even then you have to
be careful when scheduling an event in the future, if that future is on
the other side of the DST boundary, that you apply the correct timezone
transformation to the event time when converting to UTC.

iCalendar allows three ways that timezones can be handled.  One is to
use UTC.  One is to use time zones in all their glory, and one is to use
'floating time' where no time zone is specified at all.

For many activities 'floating time' is the most useful, which simply
uses the devices current timezone, and does not retain timezone
information at all.  It becomes a user-interface issue then, to allow
the user to say 'I want localised time for this resource', and choose a
timezone that applies to it at that point.


So, from an API perspective:

It would certainly be good if the API allowed for retrieving timezone
data from a central source.  That would save applications having to hold
copies of it themselves.  It would also be good if the API allowed for
bi-directional conversion between localised time & UTC.

There are a number of places, such as free/busy enquiry, where
calendaring information is always presented as UTC, so such conversion
functions will be generally useful.

A final feature that would be useful would be for the API to provide a
way of returning some standardised ID for timezones when given a
timezone specification.


Regards,
     Andrew McMillan.

------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/                     Porirua, New Zealand
Twitter: _karora                                  Phone: +64(272)DEBIAN
             How many things I can do without! -- Socrates
------------------------------------------------------------------------