[Kde-pim] KHolidays support for alternative calendar systems

[Allen Winter]

On Monday 18 January 2010 8:44:09 pm John Layt wrote:
> 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 :-)
> 
Sounds FABULOUS.
I'm so happy you're working this.

As the kholidays maintainer, I officially grant you full access to do whatever-the-hell
you want in the code.  In fact, I'd be happy to pass maintainership to you if you want it.

Don't forget to document the new syntax along the way :)
And update the DESIGN doc accordingly.

I love all your ideas.
-Allen

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