Recurring events with timezone

Hendrik Helwich 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
> > [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.
>
> 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.

Hi Gunnar,

 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 
same timezone??
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.
>
> Cheers,
>
> Gunnar
>
> > 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
> >
> > _______________________________________________
> > 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
> https://kolab.org/mailman/listinfo/kolab-format


-- 
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 mailing list