Recurring events with timezone
h.helwich at tarent.de
Wed Oct 27 12:24:10 CEST 2010
Am Donnerstag, 21 Oktober 2010 15:52:12 schrieb Tobias König:
> On Wednesday 20 October 2010 10:33:41 Joon Radley wrote:
> > Hi Andrew,
> > UTC is the constant. You calculate your local time by adjusting UTC to
> > your local time zone. If at any point your software assumes that UTC is
> > not the constant you need to revisit it.
> > Time zone and daylight savings time is a locale issue.
> I guess to cover the case Hendrik mentioned, the UTC -> local time
> conversion needs to check when the first occurence of the recurring event
> happened. Depending on the date it can find out whether it has been created
> during summer or winter time and therefor adapt the conversion of the
> current occurence from UTC -> local.
To do this you must know in which tz this event should happen to know which
DST rules should be applied.
If you use the system local tz DST rules like it is implemented right now in
the clients, people in different tzs would use different rules and the UTC
times could be different for the same event.
You need to convert the start time like
event tz -> UTC -> client tz
on every client to show the correct time.
Right now it is implemented like:
UTC -> add local DST difference of start date / recurring date -> client tz
So if all people are in the same tz this will show the correct time in the
local tz of the people. But if someone is in a different tz they could have
different UTC times for a recurring event date.
> If it has been created during winter time and the current occurence is
> winter time as well, then the normal offset is added to UTC. If it has been
> created during summer time but the current occurence is winter time, then
> the hours to add to UTC must be adapted properly.
> However this is something for the local conversion, nothing that needs
> saving timezones inside the format.
More information about the format