W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2009

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

From: <Jere.Kapyaho@nokia.com>
Date: Tue, 3 Nov 2009 21:40:47 +0100
To: <public-device-apis@w3.org>
Message-ID: <C71661EF.94C2%jere.kapyaho@nokia.com>
On 25.8.2009 16.28, "ext Device APIs and Policy Working Group Issue Tracker"
<sysbot+tracker@w3.org> wrote:
> ISSUE-7: Gathering requirements [Calendar API]
> http://www.w3.org/2009/dap/track/issues/7
> Raised by: Robin Berjon
> On product: Calendar API
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
2) instances of Coordinated Universal Time (UTC) [2];
3) either of the above, with some powerful magic to do the right

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.

Furthermore, users will definitely want to input times of new calendar
events in their own local time. If the API would take in UTC times, somebody
has to convert the local timestamp to UTC. If the app does it, there is a
risk of getting it wrong, so the conversion might be better offloaded to the
API layer, but even then the time zone information is still needed from the

If the API takes in local times, the time zone information still needs to
come from somewhere, so that it can be attached to the timestamp. Otherwise
the timestamp is basically meaningless, because without the timezone there
are a myriad different ways to interpret the time.

As you see, the issue could be moderately complex (it affects not only
create, but find, too), and I'm not sure I've even covered all the potential
issues above. Nevertheless, I think this should be enough to raise a
concern, ultimately to achieve both greater developer satisfaction and a
smaller number of missed meetings. :-)

To simplify the question, if the user wants to create a new calendar event
for 3 Nov 2009 1:00 PM PST, then does the event-creating API take a
timestamp that reflects that exact local time (with time zone information
either passed in or implicitly obtained from a lower layer), or does it take
the corresponding UTC time? Also, should iCalendar data manipulated by the
Calendar APIs then canonically carry time zone information?

And the top-level question that sparked off this e-mail is, should the
answer to the above be reflected in the requirements document?


[1] <http://www.w3.org/TR/2009/NOTE-dap-api-reqs-20091015/#calendar>
[2] <http://en.wikipedia.org/wiki/Coordinated_Universal_Time>
Received on Tuesday, 3 November 2009 20:41:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:13 UTC