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

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.

Kr,

[1] http://en.wikipedia.org/wiki/Tz_database & http://www.w3.org/TR/timezone/#tzids
[2] http://tools.ietf.org/html/rfc5545
[3] http://tools.ietf.org/html/rfc5545#section-3.6.5

On 12/02/2013 11:03 AM, Mounir Lamouri wrote:

On Tue, Dec 3, 2013, at 1:20, Christophe Dumez wrote:


Hi,

Please note that timezone change is not the only thing we need to
account for.
We also need to account for daylight savings. To do so, you really need
to associate each event/task with a specific timezone (which may or may
not be the same as you are in, for e.g. you receive a calendar invite
from someone in another timezone). If you don't store this information
(e.g. if you convert the event/task's  time to UTC or to your system's
timezone), then you will have no way to account for daylight savings as
those are specific to each timezone / country.

This kind of use case is especially important for calendar applications.



Indeed. However, it is not clear to me how using TimezoneDirective would
help.

As far as I understand it, when a country has daylight saving TZ, it
technically has two timezones and swtich from one to another during the
year. France, for example, will use CET (UTC+1) and CEST (UTC+2). I
guess that there are two approaches that we can take here: whether we
give knowledge of the daylight saving information to the application or
the API could ask for a timezone in a format like "Europe/Paris" in
which case the system could take care of the TZ changes. I do not know
enough about timezones to have an opinion on this, though.

-- Mounir




--
Christophe Dumez - Samsung Telecommunications America