Recurring events with timezone

[Hendrik Helwich]

Hi Georg,

Am Montag, 11. Oktober 2010 12:01:09 schrieb Georg C. F. Greve:
> Hi Hendrik,
>
> On Monday 11 October 2010 10.55:58 Hendrik Helwich wrote:
> > 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.
>
> This vaguely reminds me of the date field discussions we had about OOXML,
> where Microsoft wanted to keep its (known broken) date format.
>
> Storing in a variable base seems fundamentally broken to me, in particular
> when you take multiple time zones into account. So when a meeting takes
> place in two timezones which switch to daylight saving time at different
> times, when is that meeting supposed to be? Which of the local time stores
> wins?

Do you mean it would be nicer if it is not possible to define the same time in 
different ways (like with timezones) and there should be a unique way to do 
so (like UTC for single events)?
I think you have the use case that somebody wants to create a recurring event 
in his local time zone and somehow we must store this information. So there 
must be added some parameters to the kolab format and together with a defined 
algorithm it must be possible to convert the times of a recurring event to 
the UTC times.

> If it is stored in UTC, at least there is a firm point of reference against
> which it can be calculated. But there should be some way to identify what
> happens in these DST conflicts. IIRC my discussions with Bernhard that has
> been on the list of issues to resolve for the format for some time now.

i think you mean this thread?:

http://kolab.org/pipermail/kolab-format/2009-February/000880.html

> So the question is: What would be the right way of treating it?
>
> Storage in UTC, as before, with an additional field that defines the
> behaviour for DST? I could envision such a field to define that an event
> (a) stays with UTC, or that (b) it stays synchronous with local time zone
> X.

This could be a solution. Not recurring events/tasks could stay in UTC format.
For times of recurring events/tasks i think it should be possible to convert 
iCalendar times+timezones to this general kolab time. But maybe its more 
complicated than storing the DST.

Look for example at the DST in Brazil 
(http://en.wikipedia.org/wiki/Time_in_Brazil).

Another solution would be to optionally add the time zones like in iCalendar.
UTC format would still be possible. The client could convert the time of an 
event to UTC by the given rules in the kolab xml and convert it then to the 
clients local time zone.

I am working with libical at the moment and i think it could also be helpful 
to look how they are doing it to derivate the needed parameters to a kolab 
format extension:
http://freeassociation.svn.sourceforge.net/viewvc/freeassociation/trunk/libical/zoneinfo/

Greets,
Hendrik

> That might be a clean solution. But how would this work with
> synchronization, e.g. the ActiveSync protocol? Does anyone know off the top
> of their head how this is handled there?
>
> Best regards,
> Georg

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