Recurring events with timezone

Hendrik Helwich h.helwich at
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,
> Hej,
> > 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.

Hi Tobias,

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.

Best regards


> 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.
> Ciao,
> Tobias

More information about the format mailing list