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?
In general EgwIcal distinguishes between two different types of time descriptions for an event. An event can either be a:
-
DATETIME (DT) (described) event.
In this case the occurence of the event is described as taking place on a certain day and within that day on a certain time. E.g. mon 12 june 2006 at 12:33 GMT+001
Examples are: the opening of the Olympic games.
DT events are thus absolute (in global world time) anchored in time: everyone watching live TV, anywhere in the world can see it happen at that same moment described by DT.
Result is that a DT described event will occur at different hours or even days in different timezones. (Some people have to watch the Olympic game openings at night..)
-
DATE (D) (described) events
These events donot happen at an absolute global time but are only well defined relative to a timezone. A good example is "your birthday" or "new years day".
In principle this could be either whole day events (like birthdays) or events timed within days (like the "easter sunday service at 12:00").
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:
- RE.1 (I am not 100% sure:) Egw tries to handle DATE events relative to the UserInterface its timezone: the so called USER-TIME.
and for EgwIcal:
- REI.1 EgwIcal tries to handle DATE events relative to the UserInterface timezone (USER-TIME) of the IcalSrv proces of the logged in user.
and keep in mind:
- REI.2 EgwIcal currently will only import or export DATE events for whole day events or for occurence settings of recurrent events
In the following sections I will explain a bit more what this means for import of Ical data from clients and export to it.
.....
No VTIMEZONE ical elements are parsed or used This has a consequence:
- no basic import timezone setting via this supported
- no imported timezones with identifiers that can be referenced by VEVENTS or VTODOS are supported
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 is ust interpreted as relative to the USERTIME of the IcalSrv process: any timezone info is neglected.
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:
-
first the START and (if there UNTIL) dates are converted to UTC dates. Then these are converted to the IcalSrv locale setting.
-
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.
On export ....
- all Egw DATETIME info is exported in UTC time.
- all Egw DATE info is exported without any timezone info, and thus should best be considered in the USERTIME of the IcalSrv process.
On export Recurrence Rules are interpreted as follows:
-
the START date, if in DATE-TIME format is converted to UTC. If it is in DATE format exported right away, thus being in the IcalSrv local timezone: this may be wrong, but best possible!.
-
If there, an UNTIL date this is exported as UTC
Hope this explains things a bit.
Jan
Generated on Thu Jun 8 21:57:23 2006 for EgwIcal by
1.4.6