Recurring events with timezone

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


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

>
>
> Am Montag, 11. Oktober 2010 10:03:04 schrieb Gunnar Wrobel:
>> Hi Hendrik,
>>
>> Zitat von Hendrik Helwich <h.helwich at tarent.de>:
>> > Am Sonntag, 10. Oktober 2010 21:59:37 schrieb Gunnar Wrobel:
>> >> [..]
>> >> I don't see a direct limitation there. The conversion to UTC is
>> >> certainly possible and valid while you are doing it to and from one
>> >> timezone. I see a problem once you are looking at the same event with
>> >> a client in a different timezone.
>> >>
>> >> And to be honest I believe there are still some significant problems
>> >> when it comes to timezones on the Kolab server.
>> >>
>> >> But maybe you can detail what the exact problem that you are having
>> >> with the conversion is.
>> >
>> > Hi Gunnar,
>> >
>> > ok i should have made an example:
>> > * person A has a client which stores events in iCalendar data (like
>> > evolution)
>> > and creates a recurring event which occurs every Monday at 8:00 in the
>> > german time zone
>> > * person B has a kolab client like kontact and needs to attend this
>> > event. The
>> > time of this event need to be converted to UTC format due to the kolab
>> > format. So in the kolab server the start time is stored with 6:00 UTC due
>> > to the german time zone difference of two hours from UTC time.
>> > * person B is also in the german time zone. The kolab client of person B
>> > will add 2 hours to the stored UTC time and the shown start time will be
>> > 8:00. So everything is fine till now
>> > * In germany at 31.10.2010 the difference of the local time to UTC
>> > changes form 2 to 1 hour due to the daylight saving time.
>> > * the shown start time of the event will be still 8:00 for person A but
>> > 7:00 for person B because the kolab client will only add one hour to the
>> > stored UTC time 6:00.
>>
>> This last point is something I don't understand. Both persons are
>> still in the same time zone, are they not? If so why does the "kolab
>> client" only add one hour then?
>
> Hi Gunnar,
>
> This is right, both clients are in the same timezone. But the client  
> of person
> A (evolution) stores the time in local time and the client of person B
> (kontact) stores the time in UTC format.

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.

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

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

Cheers,

Gunnar

>
> Greetings,
>
> Hendrik
>
>
>> >> I could imagine that you might also be able to solve your specific
>> >> problem by adding a custom attribute to the event XML.
>> >
>> > It would be possible to preserve the time zone information of
>> > calendar data by
>> > adding custom tags.
>> > Unfortunately this would not solve the problem because the time zone
>> > information would not be considered by a kolab client if time zone data
>> > is nor part of the kolab format.
>>
>> Yes, I assume that we need to add this. But I didn't put any research
>> into it at the moment. I would need to check what we already did in
>> that area and what the problems might have been.
>>
>> Bernhard, do you have a quick comment on this? If not I'll go search
>> the issue tracker and our archives :)
>>
>> Cheers,
>>
>> Gunnar
>>
>> > Greets,
>> > Hendrik
>> >
>> >> Cheers,
>> >>
>> >> Gunnar
>
> _______________________________________________
> 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