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.

At the root of the problem is the iCalendar standard.  While it includes the
CALSCALE property to define what Calendar System the file dates are in, the 
only valid value is GREGORIAN.  No alternative Calendar Systems are defined, 
so no app can implement alternatives in a standard or interoperable way.

Most apps ignore alternatives completely and only support Gregorian (e.g. 
Evolution for now).  Some apps fake it by transparently converting dates to 
Gregorian (KOrganizer, Apple iCal).  Converting works for single-occurrence 
events, but fails with recurring events which start on the right date but then 
recur on the wrong dates.

Outlook supports recurring events in alternative Calendar Systems internally, 
but doesn't export them. Exchange defines X-MICROSOFT-CALSCALE at 
http://msdn.microsoft.com/en-us/library/ee237520.aspx but doesn't define the 
calendar formulas or recurrence rules used and doesn't export via webDAV.

Short term, the simplest option for KOriganizer might be for the recurring 
event gui to be shown in Gregorian with a message that recurrences are 
unsupported in the users Calendar System.

Another option might be for KOrganizer to only use Gregorian in the gui.  Or 
to be more technically correct and future-proof, the primary Calendar System 
used should be the CALSCALE of the users Default Calendar resource.  This 
would require better support for the display of a secondary Calendar System 
alongside the default Gregorian in the gui.  This is currently done only for 
Hebrew via a plugin.  It might be better to directly support the selection of 
any of our supported Calendar Systems as 'Primary' and 'Secondary' in the main 
settings, with the rule that one must be the default CALSCALE (i.e. 
Gregorian), and perhaps allow overrides for the Language and Digit Set to 
display in.

Long term it would be great to have the iCalendar standard include definitions
of alternative Calendar Systems, but I see that the standard has just been
revised by RFC5545 and the issue was again discussed and deferred, so this
could be some way off even if we try get involved to push for it. There's also 
the problem that most implementations probably don't even bother checking the 
CALSCALE to see if they are compatible. 

Any such formal definitions would also be useful for any new standard for 
holiday files.

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

This would allow us to internally support recurrences without any restriction 
other than requiring an end date.  Externally, other apps would still be able 
to use the file with the only restriction being unable to edit the recurrence 
rule itself.  Rules may be needed for what resource types this is enabled for.

This allows mixing recurrences for multiple Calendar Systems inside a single 
calendar file, but for future standards compatibility and better user 
visibility it might be better to restrict it to a single Calendar System per 
calendar file.

The same problem applies to birthdays set up in Contacts.  The users 
Calendar System is displayed for entering the birth date but it is stored in 
VCARD as Gregorian.  When used as a resource in KOrganizer the recurrences 
are calculated using Gregorian.

For Contact's birthdays, a similar approach could be taken:
* Short term display/edit Contact birthday in Gregorian only
* Medium term have a birthday Calendar System combo in Contacts and save an X-
KDE-BDAY-CALSCALE parameter in the VCARD
* Long term maybe get a birthday CALSCALE added in the VCARD standard.

I realise you have very limited resources and this is a niche feature (well 
besides those billion or so potential Chinese users :-), and I'm not sure I 
can promise much help with implementation short term, but these are some 
things to keep in mind and I'm definitely available to discuss design.  My 
todo list is currently around implementing lunar calendar systems and creating 
formal definitions for the calendar systems and their recurrence rules, which 
I hope will eventually lead into working on this and a new KHolidays.

Cheers!

John.
_______________________________________________
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/