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
Hendrik
> Best regards,
> Georg
More information about the format
mailing list