Timezone / recurrence scheduling discussion for Kolab

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at kolabsys.com
Fri Nov 5 22:47:23 CET 2010

On Wednesday, November 03, 2010 05:08:54 pm Georg C. F. Greve wrote:
> 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?

The XML element, event in this instance, has a version attribute that is 
currently still set to 1.0, and it could be used to let the client know how to 
deal with the what is then information of the legacy time inside the element.

Kind regards,

Jeroen van Meeuwen

Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/format/attachments/20101105/5af6b251/attachment.html>

More information about the format mailing list