W3C home > Mailing lists > Public > public-sysapps@w3.org > December 2013

Re: [Task Scheduler] Can we really remove TimezoneDirective argument?

From: Marcos Caceres <mcaceres@mozilla.com>
Date: Tue, 3 Dec 2013 10:24:54 +1000
To: Christophe Dumez <ch.dumez@sta.samsung.com>
Cc: Mounir Lamouri <mounir@lamouri.fr>, Gene Lian <clian@mozilla.com>, "public-sysapps@w3.org" <public-sysapps@w3.org>
Message-ID: <06BAE2B471D84961AB92F0AB326DFCBF@mozilla.com>

On Tuesday, December 3, 2013 at 3:03 AM, Christophe Dumez wrote:

> Hi,
> In practice, a lot of systems use the Olson Database [1], where ids look like: "America/New_York" / "Europe/Paris".
> They are listed under /usr/share/zoneinfo/ on Linux. The database, contains information about standard and daylight savings time for each timezone, including changes in history.
> So Paris would have one timezone identifier, not 2.
> If you look at calendar standards, such as iCalendar [2], time zones are defined by VTIMEZONE components [3], which can contain specific subcomponents for standard and daylight time so that the time zone 
> is unambiguously defined by the set of time measurement rules determined by the governing body for a given geographic area.
> So usually, for calendar applications, we would associate each calendar event to a timezone, which would define both standard and daylight time when necessary. That timezone is not necessarily, the same as your system's or your calendar's one. Having a timezone offset is not sufficient to account for daylight saving changes.

So, the question is: is there sufficient use cases to justify having this API not deal with TZ and daylight savings? Specially given that all system will ship with a native system clock application and probably a calendaring application.  

IMO, we should not worry about TZ and daylight savings for now. There is enough utility in this API without that stuff and current OSs can continue to use their native APIs to create system clocks and calendars. I would prefer that we move towards seeing if vendors want to implement this API as is (and if a lot of people then complain about lack of timezone support we can add it in the future). 

Marcos Caceres
Received on Tuesday, 3 December 2013 00:25:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:36:18 UTC