Recurring events with timezone

Hendrik Helwich h.helwich at tarent.de
Thu Oct 28 09:33:52 CEST 2010


Hi Tobias,

Am Mittwoch, 27 Oktober 2010 18:41:34 schrieb Tobias König:
> On Wednesday 27 October 2010 16:50:25 Hendrik Helwich wrote:
> > Hi Tobias,
>
> Hej Hendrik,
>
> > Example: if i have a local german tz and i create a recurring event from
> > today which starts at 16:00 every day, in the kolab format there is a
> > startdate of 14:00 UTC stored (current DST offset of 2 hours) and the
> > rule to repeat this event every day. Kontact/Toltec show me a start date
> > of this event of 16:00 even if UTC offset changes due to the local DST
> > rules in the next month.
>
> Then the implementation of converting UTC->localtime for recurring events
> is broken in Kontact/Toltec!

Yes

> For recurring events the clients should not add the _current_ DST offset
> to the UTC for getting the local time, but the DST offset at the point of
> the first occurence of the event.
>
> If you create an recurring event at 16:00 (DST+2) then you want it to be
> there in (DST+1) at 16:00 as well. So you can't add the current DST offset
> for recurring events.

The correct solution for UTC would be to convert the UTC time to the local 
time for every time the event happens. So in the example given above with the 
start time of 14:00 UTC of a recurring event, it is correct to show 16:00 in 
johannesburg all the year (constant offset of 2 hours), but in germany the 
time should be shown first at 16:00 but switch to 15:00 in the next month 
when the DST offset changes in germany.

> Can you give an example where this won't work?

The problem is that it is a common use case that you want a recurring event to 
happen at a local time and you do not want that the start time changes over 
the year if you have DST in your local tz. And this cannot be managed with 
UTC time zone alone.

> > So in this example the storage xml is the same and the shown local times
> > in the clients are the same.
>
> That's correct, because UTC is always the same, it is the constant thing in
> time calculation.
>
> > But this is obviously wrong because both tzs have different DST rules and
> > the same kolab event is shown the same in the clients all the year.
>
> Like I said, that's a bug in the implementations.
>
> > This is because of trying to fix the format by applying local DST rules
> > to get the UTC time.
>
> You have to fix the clients, not the format!

Yes i agree this should be done first. But my main interest is if it is 
possible to support the use case of recurring events with a local time base 
in the kolab format.

> > No, the clients need the information of the DST rules of the events tz.
>
> No, they need the information of the DST rules of the local tz at the point
> in time when the event has been created.
>
> > Otherwise it is not possible to calculate the correct UTC times of the
> > dates.
>
> UTC is contant! You don't have to calculate it. Take UTC as the base and
> calculate all locale times from it.

Yes thats right. But the local tzs are not constant sometimes so you get 
changing local times for a recurring event. This is surely correct but 
sometimes its not what you want from a users view.

> > > No, there is no event tz, events are always stored in UTC.
> >
> > Yes this is right. But the problem is that it is done wrong in the
> > moment, so one solution would be to calculate UTC -> local correct
>
> Exactly, that's the way to do it!
>
> > or another solution would be to add event tz to the kolab format
> > and calculate event tz -> UTC -> client tz
>
> No, definitely not. If you have N timezones, then
>
>   'UTC -> local' needs N possible conversions
>
> but
>
>   'local -> UTC -> local' needs NxN possible conversion
>
> what do you think is easier to implement and maintain?

Yes i agree that timezones with DST is a mess and more complicated to 
implement and maintain than to support UTC tz only.
But the problem is that from a users view it is an important feature to 
support local tzs because from this view it is the natural modeling.
Also other formats like the common iCalendar support tzs and you have a 
problem when you want to be convert between the kolab and the e.g. iCalendar 
format. But you often need to do this e.g. if you want to enable an existing 
client to support the kolab groupware server as a storeage.

Best Regards,

Hendrik

> Ciao,
> Tobias




More information about the format mailing list