[Kde-pim] KHolidays support for alternative calendar systems

[John Layt]

Hi,

As an experiment and learning exercise, I tried to add support for alternative 
calendar systems to the current kholidays file format.  Long story short, 
after almost completely rewriting the yacc/lex parser it actually works, so 
I've decided to submit this as a feature for 4.5.

For example, a holiday file could include Islamic holidays defined in the 
Hijri calendar:

	"New Years Day" red on 1/1
	"Christmas Day" red gregorian on december 25
	"Muharram" red hijri on 1/1
	"Eid ul-Fitr" red hijri on shawwal 1

Which for 2010 will generate the following holidays:

	2010-01-01  "New Years Day"
	2010-09-10  "Eid ul-Fitr"
	2010-12-08  "Muharram"
	2010-12-20  "Christmas Day"

My plan is to work with the current file format and library to extend them to 
support as many of the desired features listed in the kholidays2 design, and 
to test their use out in the Plasma Calendar widget.  In this way I hope to 
get a clearer idea of the requirements for kholidays2, and get a more useful 
Plasma Calendar in the process.

The current state (as submitted to review board 
http://reviewboard.kde.org/r/2647/) is that the new parser correctly reads and 
calculates all the existing holiday files, can calculate alternative calendar 
systems, and parses some experimental file metadata.

What I plan to do from here is:

* Finalise the required file metadata fields (name, region, language, etc).

* Add holiday class/category syntax (e.g. Public / Religious / Cultural / 
Financial Holiday etc).  Holidays can have multiple classes/categories.

* Improve the SHIFT syntax to cater for more complex rules (e.g. the Boxing 
Day problem).  Add optional name for day shifted to.

* Add a NOOP or EXCLUDE syntax to allow holidays to only occur in some years 
and not others.

* Change the parser api to accept a required date, date range, or calendar 
year, and return a QList<Holiday>.

* If holiday has a duration > 1 day return only one Holiday instance with a 
duration and/or end date attribute set, rather than multiple Holiday 
instances.  This will allow the client app to choose whether to display as a 
singled spanned entry or multiple entries, and may make de-duping easier.

* Return attributes of both original date of holiday and shifted to 
observation date, and if original date is still a holiday or not.  Option to 
have different names shown for each date.

* Add required new fields to Holiday class.

* Possibly split the KHolidays source file into separate files for classes 
Holiday and HolidayRegion?  The parser will need to include Holiday but not 
HolidayRegion?

* Plug the new parser into HolidayRegion, add date range api in HolidayRegion.

* Split the existing holiday files up into civil and religious files and 
create a better naming scheme including country, language, region and type.

* Try sort out translation of the file names (I18N_NOOP the English names in a 
file somewhere?).

* Figure what to do with the Hebrew calendar, the mid-year leap month makes 
things tricky.

* Anything else I think of along the way.

Some of this will see a change in behaviour of KHolidays if not api/abi, but 
with only 2 current clients I think the benefits outweigh the disadvantages.

The Plasma Calendar widget will be the test case, where I will add support for 
showing multiple holiday regions, holiday types, etc.

How does that sound?  Apologies for the distraction from the Akonadi merge :-)

Cheers!

John.
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/