Recurring events with timezone

[Hendrik Helwich]

Am Montag, 11. Oktober 2010 11:29:15 schrieb Gunnar Wrobel:
>  [..]
> Hm, I assumed that you were working on getting evolution to store the
> data in Kolab XML format. You were at least referring to converting
> from iCalendar to Kolab XML. How does this exactly look like?
>
> Because I would assume that if Evolution is somehow able to convert
> between iCalender and Kolab XML then it should be able to take
> daylight saving into account, shouldn't it?
>
> You said that the clients are both in the same timezone. So I don't
> see why Evolution would fail to take this timezone into account while
> reading/writing the Kolab Format XML.

Hi Gunnar,

i am member of a project which will connect evolution with a kolab server [1] 
to use evolution as a kolab client. Right now evolution does not have the 
ability to be connected with a kolab server.
Evolution itself is using a server (which is called evolution data server - 
EDS) on the client which can be used to add a new datastore. So we are 
writing a plugin for EDS to connect it with a kolab server.
This server has a class which represents the event/task types. This class 
wraps an iCalendar string. So we are determined to map this class to a kolab 
mail (and back) if we want to connect evolution to a kolab server.
So if you create a new event in the evolution gui and use the plugin which we 
are currently developing we need to convert the local times in this event to 
UTC time to be able to store it in the kolab server.

> > 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.
>
> Yes, as long as we talk about using clients in two different
> timezones. There might be a problem there and as mentioned I'd need to
> check the status.
>
> But for two clients in the same timezone I don't see where the problem
> could originate. Both clients should be aware of daylight saving. Both
> have the information required to place events past 31.10.2010 correctly.

If you have an event in kolab you only know the start time in UTC. You cannot 
create a recurring start time like: happen at 8:00 in the german time zone 
because you cannot store the time zone in kolab. It doesn't matter in which 
time zone the kolab client is. This problem will also occur if both clients 
are in the same time zone like described before.

> >>  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.
>
> So you are saying both Kontact and Outlook display an event
> incorrectly if they are set to the German timezone and the event was
> stored in UTC within the Kolab format?

No i was saying if you have a client which wants to store a recurring event 
with a local start time and it crosses a day light saving time border it will 
be displayed incorrectly in Outlook, Kontact or any other kolab client 
because it is not possible to store this information with the kolab format.

Greetings,
Hendrik


[1] http://sourceforge.net/projects/evolution-kolab/

-- 
tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH
Geschäftsführer: Boris Esser, Elmar Geese
HRB AG Bonn 5168 - USt-ID (VAT): DE122264941

Heilsbachstraße 24,  53123 Bonn,   Telefon: +49 228 52675-0
Thiemannstraße 36 a, 12059 Berlin, Telefon: +49 30 5682943-30
Internet: http://www.tarent.de/  • Telefax: +49 228 52675-25