EgwIcal Timezone Handling

Short description on the timezone handling in EgwIcal

Date:
20060305
Version:
0.9.05
Author:
JVL
Note:
Document needs further editing and annotations!!
In EgwIcal the timed data of Egroupware like events and tasks get converted to elements for an iCalendar. In the Egroupware server we are dealing with socalled "egw server" time, in applications that a user of egw runs, the user can set a "locale" and thereby defining a "local timezone". And finally when events and task get exported to an iCalendar that is sent to a client or uploaded from it, they may also have their timesettings defined according to some "timezone".

How is this all handled in EgwIcal?

EgwIcal general Timezone handling

In general EgwIcal distinguishes between two different types of time descriptions for an event. An event can either be a:

Timeindications for DT events are often stored using a socalled unix timestamp: an integer that counts the seconds gone after some initial day in 1970. Indeed, at the moment in Egroupware the date times are stored following the rule (Ralf, is this correct?):

For handling DT events it can be profitable to use a globally unified standard for describing the timingly definitions, like e.g. UTC. And indeed:

For handling D events you can best give a (timezone/geo) relative description together with the GEO location. Then someone who wants to visit such a event can checkout the location and see what timezone they have there at moment of the event, calculate it back to UTC and then she knows when to get there. Egw and EgwIcal are no very sophisticated in handling these:

and for EgwIcal:

and keep in mind:

In the following sections I will explain a bit more what this means for import of Ical data from clients and export to it.

EgwIcal Timezone handling for icaldata import from a client.

.....

VTIMEZONE import handling.

No VTIMEZONE ical elements are parsed or used This has a consequence:

DATETIME formatted data import handling.

DATETIME formatted data is inspected for its timezone. If the timezone is UTC ('Z') then it is converted (i.e. copied) to UTC before processing further. If the timezone is not given of is referenced with a key to a VTIMEZONE component in the Icalendar file, this timezone info is discarded and a "timezoned" DATETIME is just interpreted as relative to the USERTIME of the IcalSrv process: any timezone info is neglected.

Clearly this can be wrong in many occasions: thus this should be considered a BUG!

DATE formatted data import handling.

DATE formatted data is ust interpreted as relative to the USERTIME of the IcalSrv process: any timezone info is neglected.

Importing Recurrence Elements

Doing recurrence calculation in UTC is notably not a good thing to do because DayTime Savings changes during the runtime of the recurring event can cause troubles. The best thing to do is to calculate the recurrence in the geo/time-zone of the definer. See ... of the CAlConnect Group for this. But as clients often dont export their timezones, (and we dont do any processing of it anyhow) we do the following:

  1. first the START and (if there UNTIL) dates are converted to UTC dates. Then these are converted to the IcalSrv locale setting.

  2. Then the recurrence rules are evaluated, and converted to the info Egw needs. Note: Egw cannot use the COUNT field, so EgwIcal has to rewrite it to a UNTIL value.

EgwIcal Timezone handling for icaldata export to a client.

On export ....

Exporting Recurrence Elements

On export Recurrence Rules are interpreted as follows:

Hope this explains things a bit.

Jan


Generated on Thu Jun 8 21:57:23 2006 for EgwIcal by  doxygen 1.4.6