WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
> 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.