Recurring events with timezone

Gunnar Wrobel wrobel at kolabsys.com
Mon Oct 11 15:07:24 CEST 2010


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.

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

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




More information about the format mailing list