Recurring events with timezone

Hendrik Helwich h.helwich at tarent.de
Mon Oct 11 10:55:58 CEST 2010



Am Montag, 11. Oktober 2010 10:03:04 schrieb Gunnar Wrobel:
> Hi Hendrik,
>
> Zitat von Hendrik Helwich <h.helwich at tarent.de>:
> > Am Sonntag, 10. Oktober 2010 21:59:37 schrieb Gunnar Wrobel:
> >> [..]
> >> I don't see a direct limitation there. The conversion to UTC is
> >> certainly possible and valid while you are doing it to and from one
> >> timezone. I see a problem once you are looking at the same event with
> >> a client in a different timezone.
> >>
> >> And to be honest I believe there are still some significant problems
> >> when it comes to timezones on the Kolab server.
> >>
> >> But maybe you can detail what the exact problem that you are having
> >> with the conversion is.
> >
> > Hi Gunnar,
> >
> > ok i should have made an example:
> > * person A has a client which stores events in iCalendar data (like
> > evolution)
> > and creates a recurring event which occurs every Monday at 8:00 in the
> > german time zone
> > * person B has a kolab client like kontact and needs to attend this
> > event. The
> > time of this event need to be converted to UTC format due to the kolab
> > format. So in the kolab server the start time is stored with 6:00 UTC due
> > to the german time zone difference of two hours from UTC time.
> > * person B is also in the german time zone. The kolab client of person B
> > will add 2 hours to the stored UTC time and the shown start time will be
> > 8:00. So everything is fine till now
> > * In germany at 31.10.2010 the difference of the local time to UTC
> > changes form 2 to 1 hour due to the daylight saving time.
> > * the shown start time of the event will be still 8:00 for person A but
> > 7:00 for person B because the kolab client will only add one hour to the
> > stored UTC time 6:00.
>
> This last point is something I don't understand. Both persons are
> still in the same time zone, are they not? If so why does the "kolab
> client" only add one hour then?

Hi Gunnar,

This is right, both clients are in the same timezone. But the client of person 
A (evolution) stores the time in local time and the client of person B 
(kontact) stores the time in UTC format.
The problem here is that the difference of the UTC time to the local time 
changes in some timezones (like in germany) due to the daylight saving time.
So in germany the difference is two hours in the summer and one hour in the 
winter. If you have a recurring event it could cross this border.
So if you pass the 31.10.2010 the event should take place at the same local 
time but this means the related UTC time will be one hour later. And this 
cannot be expressed with the kolab format i think.

>  And which client do you refer to exactly with "kolab client"? Kontact?

I wrote kolab client because i think this problem happens because of the 
design of the kolab format and so it should occur in any kolab client.
But we are using Kontact and Outlook/Toltec Connector.

Greetings,

Hendrik


> >> I could imagine that you might also be able to solve your specific
> >> problem by adding a custom attribute to the event XML.
> >
> > It would be possible to preserve the time zone information of
> > calendar data by
> > adding custom tags.
> > Unfortunately this would not solve the problem because the time zone
> > information would not be considered by a kolab client if time zone data
> > is nor part of the kolab format.
>
> Yes, I assume that we need to add this. But I didn't put any research
> into it at the moment. I would need to check what we already did in
> that area and what the problems might have been.
>
> Bernhard, do you have a quick comment on this? If not I'll go search
> the issue tracker and our archives :)
>
> Cheers,
>
> Gunnar
>
> > Greets,
> > Hendrik
> >
> >> Cheers,
> >>
> >> Gunnar




More information about the format mailing list