Timezone / recurrence scheduling discussion for Kolab

David Jarvie djarvie at kde.org
Wed Nov 3 13:21:23 CET 2010

On Wed, November 3, 2010 9:12 am, Georg C. F. Greve wrote:
> Hi David, John, Sergio,
> Tobias told me you're the people to contact about time zone issues.
> Background is that several people identified a gap in Kolab's handling of
> recurring events when multiple time zones are involved, and we're
> wondering
> how to resolve this. An explanation of the issue can be found here:
>  http://kolab.org/pipermail/kolab-format/2010-October/001004.html
> For simplicity, I've come to refer to this as "the 'sticky' time zone
> issue" and here is a short summary of proposed solutions:
>  http://kolab.org/pipermail/kolab-format/2010-October/001006.html
> The people who work on native Kolab support for Evolution have proposed
> (and
> begun to implement) the following approach:
>  http://kolab.org/pipermail/kolab-format/2010-October/000999.html
> But naturally this forks the format, and will break compatibility with all
> other clients, which is not a satisfactory outcome.
> So we should find a good way to approach this issue.
> The question to you is: From your experience, which would be the most
> sensible
> approach, and would disrupt Kontact the least, with the least disruption
> of backward compatibility?

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.

If this isn't possible in Kolab storage, it may not be easy to make it
work. Storing in UTC is a fudge, since the meeting time is not specified
as a fixed UTC time.


David Jarvie.
KDE developer.
KAlarm author - http://www.astrojar.org.uk/kalarm

More information about the format mailing list