[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Non-Gregorian Calendar Systems in KOrganizer
From:       David Jarvie <djarvie () kde ! org>
Date:       2009-12-15 0:49:13
Message-ID: 200912150049.13540.djarvie () kde ! org
[Download RAW message or body]

On Monday 14 Dec 2009 18:14:15 John Layt wrote:
> Hi,
> 
> I'm sure you are aware of the issues with non-Gregorian Calendar Systems and 
> recurring events in KOrganizer.  As I hear KOrganizer is undergoing a re-write 
> for Akonadi, and I've had people asking me about the issues,  I thought I'd 
> ask what the future plans for this were, and share my ramblings about it.
> 
> A user who has their desktop set to an alternative Calendar System when they 
> run KOrganizer will see a gui using their Calendar System.  This works fine 
> for single occurrence events, the problem comes when creating a new or editing 
> an existing recurring event.  The user will use a gui in their Calendar System 
> and assume the recurrence is calculated in that Calendar System, but the event 
> will recur using Gregorian calendar rules instead.

This is something which KAlarm would also want to implement. I've been aware of this \
issue for some time, but for reasons of the iCalendar format limitations which you \
mention, it seemed a big job to tackle.

> Medium term, A quick read of the standard suggests a possible way to support 
> recurring components in alternative Calendar Systems without changing the 
> standard or compromising interoperability.
> 
> 1) Define new extension properties X-KDE-RRULE and X-KDE-RRULE-CALSCALE (or 
> agree an FDO namespace)
> 2) In the recurrence gui add a combo to choose Calendar System
> 3) If the user selects Gregorian then everything continues as normal.
> 4) If the user selects an alternative, then:
> * require the entry of an end date or condition
> * save the RRULE property as X-KDE-RRULE instead
> * save the Calendar System as X-KDE-RRULE-CALSCALE
> * calculate all the recurrence dates in the chosen Calendar System
> * convert all the recurrence dates into Gregorian
> * save all the Gregorian recurrence dates using RDATE
> * all dates saved in the file remain in Gregorian as normal
> 5) Internally always use X-KDE-RRULE if present and not RDATE

Although this would often work, it would fail or become impractical in two cases:

 - a recurrence without an end date (as you recognise).

 - a relatively frequent recurrence with an end date a long time from now, i.e. one \
with a very large number of occurrences. This could make for a very large calendar \
entry.

I suspect that recurrence rules with large numbers of occurrences might become quite \
inefficient to process in applications, although of course KDE applications which are \
able to make use of the X-KDE-RRULE entries wouldn't suffer from this problem any \
more than currently. Already, some recurrence calculations can take quite some time \
to process, and if they consisted of a long list of individual date/time values, they \
might become even more time consuming. 

So I think that we'd need to impose arbitrary limits both on end date, and on how \
many RDATE instances would be stored.

Apart from these reservations, your proposals seem a reasonable approach for tackling \
this issue, providing people can spend the necessary time to implement them.

-- 
David Jarvie.
KDE developer.
KAlarm author -- http://www.astrojar.org.uk/kalarm
_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/


[prev in list] [next in list] [prev in thread] [next in thread]