Timezone / recurrence scheduling discussion for Kolab

Hendrik Helwich h.helwich at tarent.de
Wed Nov 3 16:41:58 CET 2010

Am Mittwoch, 3 November 2010 18:08:54 schrieb Georg C. F. Greve:
> On Wednesday 03 November 2010 13.21:23 David Jarvie wrote:
> > I'm not familiar with how Kolab stores its data, so I don't know what
> > restrictions there are. From my experience, the only way to make this
> > work reliably is to store the recurrence time as a local time with
> > associated time zone (which is how the meeting time is actually specified
> > by the person organising it), as in iCalendar. Then each client can
> > convert the time to its own time zone, without any risk of error.
> That is one of the proposed solutions, yes.
> The only issue I currently see with it would be that we'd likely break
> backward compatibility, so there is a chance of confusion/data corruption
> between clients supporting format <=2.0, which assume storage in UTC, and
> those supporting 2.1 and greater, which would then store local time, both
> using the same tag for storage.
> Does anyone have a good idea how to avoid this in a non-ugly way?

Hi Georg,

my suggestion is to add an optional timezone XML element. The start and end 
time of an event could anyway be stored in UTC format. If the timezone 
element is available, the start and end time of the event could be 
transformed in a local time with the stored timezone information. If the 
timezone element is missing, the UTC timezone will be used.
So this would be compatible with the old format.
With a missing timezone element it will have the same semantic like in the old 
format. If the timezone element is available and a recurring event does not 
cross a DST border, it also would be shown correctly in clients which only 
support the old format version.

Best regards


> Best regards,
> Georg

More information about the format mailing list