Recurring events with timezone

Gunnar Wrobel wrobel at kolabsys.com
Mon Oct 11 15:55:03 CEST 2010


Zitat von Hendrik Helwich <h.helwich at tarent.de>:

>
>
> 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.

Yes, as long as the other clients are in a different timezone than the  
one in which the event was created.

>
>> >> > 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??

Yes, this is what I mentioned before.

> After i understand the kolab format is completely time zone free and you can
> not know in which time zone the event should happen

It is undeniably a shortcoming of the format that needs fixing. I  
don't know why this hasn't been tackled more aggressively so far as I  
also don't think it is very difficult to fix.

But so far the problem apparently did not occur too often. Though I  
must admit that I would expect a groupware server to be tackled with  
this particular problem more and more often as meetings spreading over  
different timezone are not that uncommon nowadays - as Andrew also  
noted.

Cheers,

Gunnar

>
>> >> >>  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
>
> _______________________________________________
> 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.




More information about the format mailing list