Recurring events with timezone
h.helwich at tarent.de
Mon Oct 11 15:27:30 CEST 2010
Am Montag, 11. Oktober 2010 15:07:24 schrieb Gunnar Wrobel:
> Hi Hendrik,
> Zitat von Hendrik Helwich <h.helwich at tarent.de>:
> > 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
> >  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.
> Ah, now it makes sense to me. So you are having a middle layer (EDS)
> in between Kolab XML and Evolution and I assume that this layer is
> itself *not* aware of the clients timezone. But as this is the part
> doing the actual conversion you run into trouble. For this I see no
> problem in adding a custom attribute for your connector. It should
> probably store the timezone the event was originally created in. That
> should allow you to convert the event back into its original form on
> the client side.
surely it is possible to store my own timezone data in custom kolab fields.
The problem is that other kolab clients can't understand it and will display
a wrong time in the described scenario.
> >> > 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.
> That is not correct. What the Kolab Format currently supports without
> a problem is clients in the same time zone. The events do have a
> defined and fixed starting point in UTC (not just the time but also
> the date is known for the first recurrence). Currently a Kolab client
> has to assume that the events are meant for the local time zone. As
> the first recurring event has a known date the client also knows which
> daylight saving period this will match to. If the first recurrence of
> an event occurred at 8 AM in the German timezone the client must
> assume that this is also true for all following events. This is
> sufficient for the "clients in the same timezone" situation.
You mean a kolab client will assume that all other kolab clients are in the
After i understand the kolab format is completely time zone free and you can
not know in which time zone the event should happen
> >> >> 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.
> I can't confirm that for the webmail client for example. We do have
> recurring events that always occupy the same time slot both in October
> and November of this year.
> > Greetings,
> > Hendrik
> >  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
> > _______________________________________________
> > Kolab-format mailing list
> > Kolab-format at kolab.org
> > https://kolab.org/mailman/listinfo/kolab-format
> Gunnar Wrobel
> Developer, Kolab Systems AG
> e: wrobel at kolabsys.com
> t: +49 700 6245 0000
> w: http://www.kolabsys.com
> pgp: 9703 43BE
> This message was sent using IMP, the Internet Messaging Program.
> Kolab-format mailing list
> Kolab-format at kolab.org
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
More information about the format