[Kde-pim] Re: Hungarian holidays && issues with holiday parsing and the calendar display

John Layt johnlayt at googlemail.com
Mon Jan 31 19:21:40 GMT 2011


On Monday 31 January 2011 14:52:21 Szokovacs Robert wrote:
> Hi,
> 
> Attached is an updated and extended version of the holidays file for
> Hungary (plan2 directory - I guess thats the current one), please consider
> it for inclusion!

Many thanks, I'll update that once I have a working Git check-out.  Could I 
just ask that you open a wish in bugs.kde.org under kdepimlibs/kholidays and 
attach the file so I don't lose track of it?

> While I was creating this file, I noticed the following issues:
> 
> a, of the following two:
> 
> "Nagypéntek"                            on friday before easter
> "Nagypéntek"                            on easter minus 3
> 
> only the second one works (Nagypéntek is Good Friday), I'm not sure if the
> first should work, but if it did, I would've used it :)

The plan grammer is really obtuse at times and makes my head hurt, which is 
why I'm planning to replace it soon.  Perhaps try:

"Nagypéntek"                              on friday before ([easter])

> b, If a line is syntactically incorrect (for example the one with "before
> easter", the subsequent lines are ignored - I think this is a bug.

Unfortunately I can't do much about that, the parser reads and validates and 
evaluates the file as a whole in a single pass and stops when it reaches the 
first error.  I could implement a less efficient line-by-line multi-pass mode, 
but I won't as any file we distribute must be tested first so won't have 
errors, and I'd rather spend the time implementing a new format and parser.  
If the parser finds an error then the api shouldn't return any holidays to the 
client app, let me know if it does as that would be a bug.

> c, The calender viewed from the digital clock applet marks the current day.
> If the day of the month is 29th, 30th or 31th, and we switch the month to
> february, the "current day" mark marks the last day of the month (=28th),
> which is good, but if we switch the month yet again, it will stay at 28th,
> which is a bug. The same thing happens if the current day is 31th and we
> switch to a month with 30 days. If we switch back to the current month,
> now there is two "current day" marks.

Well, that's a plasma issue, but I also maintain part of that so can comment. 

The black halo is the "Today" marker and the blue halo is the "Currently 
Selected" marker which is also shown in the date edit line at the bottom, 
these are two separate and unrelated dates but when first displayed are the 
same day.  You can change the "Currently Selected" by simply clicking on any 
day number, which is one way you can have two separate days highlighted, so 
that's not actually a bug, just a side-effect of the day number not remaining 
consistent while navigating.

Keeping the day number consistent while navigating over long/short months 
(sometimes known as "reference days" in the banking industry) may make sense 
for the scenario where you want to see what weekday a day number falls on in 3 
months time, but may be confusing for other scenarios, so that would be a 
50:50 design call.  Please raise a bug in b.k.o against plasma/widget-clock so 
we can think about it.

> d, Regarding the semantics of the "before" in the holiday file:
> "Advent negyedik vasárnapja"            on sunday before december 24
> (forth sunday of advent)
> it seems that the before means "before or that day", which wasn't intuitive
> for me (I put 25th there at first and then saw that this years december
> 25th is sunday and it was marked as advent and christmas too)
> [A quick grep shows an agreement in the position of advent in the different
> contries, except for iceland - so probably iceland's file is buggy
> currently]

Yes, the inherited Plan file format is not the best particularly given how we 
abuse their keywords.  I have been thinking of adding more keywords as 
synonyms to make it easier to read if not write (e.g. holiday == weekend), but 
due to backwards compatibility I can't fix the "before" to behave in the 
"correct" way, and adding better named keywords may be tricky given the way 
the parser works by reducing every rule to a mathematical expression to be 
evaluated ("before" effectively means "* -1").

I'm hoping 4.7 will be the last release using the Plan format and parser, that 
the last few classification requirements I'm adding will be sorted in 4.7 
meaning in 4.8 I can try implement a new xml based file format using 
attributes that will be easier to read and write using an evaluation that 
works in a procedural manner based on the attribute keywords and values.

I'll fix the Iceland file for Advent.

> e, The term "weekend" is used to mark the day-off-work holidays, the
> calender viewed from the digital clock applet displays them correctly, but
> the calendar view in kontact or the korganizer threats them always as a
> two days long holiday.

I'm not sure I understand this, can you give an example or link to a screen 
shot?  Do you mean any "weekend" rule without a "duration" clause is showing 
up in korganizer as 2 days rather than 1?  If so, what version of korganizer 
and kdepimlibs is this with?

Thanks for the feedback!

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/



More information about the kde-pim mailing list