Recurring events with timezone

Tue Oct 19 05:54:52 CEST 2010

Hi Hendrik,

There is no reason for this time zone information to be added.

The format is universal and the client should adjust UTC to fit the users locale.

All other Kolab clients have been able to successfully implement the UTC concept.

Best Regards

Joon Radley

Cell: +27 (0)83 368 8557
Fax: +27 (0)86 547 2353
E-mail: support at toltec.co.za
Web: www.toltec.co.za

On 18 Oct 2010, at 3:43 PM, Hendrik Helwich wrote:

> Hi,
> 
> for our effort to connect evolution with the kolab groupware server we would 
> like to know if it is possible to add timezone data to the kolab format. We 
> just put the implementation of this issue on hold as long as possible to not 
> exceed the deadlines to the customer. 
> At 31.10.2010 we finally need to start the implementation of this timezone 
> issues and would be glad if a decision to add timezone data to the kolab 
> format or not could be made :-)
> 
> I think to be interoperable with other calendar formats (like the frequently 
> used iCalendar format) and to describe the common usecase that a recurring 
> event should happen in a concrete timezone, it would be great if the kolab 
> format would support other timezones then UTC.
> I also found an informative pdf on the CalConnect Page which illustrates why 
> it is good to add timezone information to a calendar format:
> http://www.calconnect.org/pubdocs/CD0602%20iCalendar%20Timezone%20Problems%20and%20Recommendations.pdf
> 
> I still hope i can convince you to add timezones to the kolab format :-)
> Otherwise when we have to start the implementation of this issues in two weeks 
> we need to convert local times from evolution calendar data to kolab UTC 
> times and this will lead to different times displayed to users for the same 
> event/task in some scenarios as mentioned before. And i certainly would like 
> to avoid this problem if it is possible :-) I also think this would increase 
> the value of the kolab format.
> 
> Because we are in shortage of time i want to do a suggestion how timezone data 
> could be added to the kolab format. I tried to do it in a kolab style way and 
> tried to make it simple and readable. Also all used timezones should be 
> covered. For this reason i looked over all the iCalendar timezones of libical 
> at:
> 
> http://freeassociation.svn.sourceforge.net/viewvc/freeassociation/trunk/libical/zoneinfo/
> 
> They use only two different timezone types: Simple timezones which have only a 
> fixed offset to the UTC timezone and a little more complex timezones with two 
> different offsets due to the daylight saving time.
> Here is an example of a simple type:
> 
> http://freeassociation.svn.sourceforge.net/viewvc/freeassociation/trunk/libical/zoneinfo/Africa/Johannesburg.ics
> 
> BEGIN:VCALENDAR
> PRODID:-//citadel.org//NONSGML Citadel calendar//EN
> VERSION:2.0
> BEGIN:VTIMEZONE
> TZID:/citadel.org/20070227_1/Africa/Johannesburg
> X-LIC-LOCATION:Africa/Johannesburg
> BEGIN:STANDARD
> TZOFFSETFROM:+0200
> TZOFFSETTO:+0200
> TZNAME:SAST
> DTSTART:19700101T000000
> END:STANDARD
> END:VTIMEZONE
> END:VCALENDAR
> 
> I encoded the important informations in XML:
> 
> <timezone>
> 	<id>Africa/Johannesburg</id>
> 	<standard-time name="SAST">
> 		<offset>+0200</offset>
> 	</standard-time>
> </timezone>
> 
> 
> Here is one example of the second more complex example with DST:
> 
> http://freeassociation.svn.sourceforge.net/viewvc/freeassociation/trunk/libical/zoneinfo/Europe/Berlin.ics
> 
> BEGIN:VCALENDAR
> PRODID:-//citadel.org//NONSGML Citadel calendar//EN
> VERSION:2.0
> BEGIN:VTIMEZONE
> TZID:/citadel.org/20070227_1/Europe/Berlin
> X-LIC-LOCATION:Europe/Berlin
> BEGIN:DAYLIGHT
> TZOFFSETFROM:+0100
> TZOFFSETTO:+0200
> TZNAME:CEST
> DTSTART:19700329T020000
> RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
> END:DAYLIGHT
> BEGIN:STANDARD
> TZOFFSETFROM:+0200
> TZOFFSETTO:+0100
> TZNAME:CET
> DTSTART:19701025T030000
> RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
> END:STANDARD
> END:VTIMEZONE
> END:VCALENDAR
> 
> This could be encoded in Kolab-XML like this:
> 
> <timezone>
> 	<id>Europe/Berlin</id>
> 	<standard-time name="CET">
> 		<offset>+0100</offset>
> 	</standard-time>
> 	<daylight-saving-time name="CEST">
> 		<offset>+0200</offset>
> 		<start-date>
> 			<month>march</month>
> 			<day count="-1">sunday</day>
> 		</start-date>
> 		<end-date>
> 			<month>october</month>
> 			<day count="-1">sunday</day>
> 		</end-date>
> 	</daylight-saving-time>
> </timezone>
> 
> This example of the german timezone defines a standard offset of +1 hour  and 
> an DST offset of +2 hours to the UTC timezone.
> The DST offset starts on the last sunday in march (start-date is inclusive) 
> and ends the day before the last sunday in october (end-date is exclusive).
> 
> The strings in the start-date and the end-date elements of a kolab event could 
> be set without the trailing "Z" character to indicate that the defined 
> timezone should be used instead of UTC timezone.
> 
> I attached an XML Schema for the described timezone element for a better 
> understanding. This timezone element should be a top level element which is 
> optional. It would still be possible to define the kolab format with UTC 
> timezone like before.
> 
> kolab timezone elements could also easily be generated automatically by a 
> script from the given ics files of libical. This could be helpful if Kontact 
> wants to enable the user to add a timezone to an event/task sometimes.
> 
> What do you think?
> 
> Greetings,
> Hendrik
> 
> 
> 
> -- 
> 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-timezone.xsd>_______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format