Created attachment 31004 [details]
My canlendar Widget, when my system calendar system sets to Jalali

I have this issue too!
I'm using Kubuntu 8.10 , KDE 4.2

Snapshot attached.

*** Bug 185093 has been marked as a duplicate of this bug. ***

Month and Week changes are working now. But clicking on any day reproduces the bug.  kdebase r969739 and kdelibs r969859. Its a regression.

I can confirm what Praveen said.

well, testing with the Hebrew calendar system and the following code:

QDate d = QDate::currentDate();
int calYear = calendar->year(d);
int calMonth = calendar->month(d);
int calDay = calendar->day(d);
kDebug() << "For" << d << "localized date is" << calYear << calMonth << calDay;
kDebug() << "and the month name is: " << calendar->monthName(calMonth, calYear);
calendar->setDate(d, calYear, calMonth, calDay);
kDebug() << "converted back from the localized dates:" << d;

i get this with the Hebrew calendar:

For QDate("Tue May 19 2009") localized date is 5769 8 25
and the month name is:  "Iyar"
converted back from the localized dates: QDate("Tue Aug 24 -3893")

that is quite obviously wrong.

with the Jalali calendar i get:

For QDate("Tue May 19 2009") localized date is 1388 2 29
and the month name is:  "Ordibehesht"
converted back from the localized dates: QDate("Tue May 19 2009")

that is quite obviously correct.

with Hijri i get:

For QDate("Tue May 19 2009") localized date is 1430 5 24
and the month name is:  "Jumaada al-Awal"
converted back from the localized dates: QDate("Wed May 20 2009")

while that is quite obviously wrong, it's not nearly as bad as with the Hebrew calendar.

now.. guess which calendar systems work properly and which don't in the plasma calendar? answer: Gregorian works, Jalali works ... Hebrew and Hijri don't.

now, there was a bug in the Plasma calendar where it was assuming the year was 12 months long. that wasn't right, but i've fixed that one now.

at this point it looks like a kdelibs bug. i'm adding John Layt to the CC list so he can confirm/deny so we can triage this to the right place.

Hi Aaron, thanks for the triage and test cases, does look like a kdelibs bug and similar to another one we have reported already so I'll have a crack at it to get my hand back in after too many months away...

awesome; thanks John. if i knew anything about calendaring systems i'd give a crack myself, but it's really not a strong area of knowledge for me, to say the least.

if you need/want any testers though, hook me up ...

Aaron, I've been looking at the Plasma calendar code some more as KDatePicker is working fine, and there look to be a lot of bugs in there that could lead to non-Gregorian calendars not working properly.  For example, setDate() allows you to set a date outside the calendar systems valid range, there are lots of places still assuming 12 months in the year or directly using QDate methods instead of the calendar system methods, not catering for leap months, etc.  I want to go through and fix them up to match the well-proven algorithms from KDatePicker/KDateTable but thought I should check with you first that you're happy for me to do so.  I can post patches to the review board if you want.

The new populateHolidays() stuff also has a lot of code that assumes Gregorian months rather than the actual month displayed, e.g. month Foo in calendar Bar may in fact be 11 March to 5 April in Gregorian and asking for all holidays in March instead of Foo may not be right.  I haven't looked at the data engine or PIM side yet to see if Gregorian is actually what is needed, but I suspect not.  Are you also happy for me to hack at this?

Finally, there do appear to be some round trip issues with date conversions which I think lie with the formula's currently used, e.g. Jalali we know is wrong outside a limited range, but I'm struggling to find a correct and free formula for the full date range.  However, none of these should actually be causing the problems seen as KDatePicker works ok in spite of them.

SVN commit 981658 by jlayt:

Rather large change this, but most of it is inter-dependent and required to
fix the non-Gregorian calendar support.  And I just have a bad (?) habit of
cleaning things up as I go along...

Changes:

* Re-write most of the date and calendar code (recycled from
  KDatePicker/KDateTable) to properly cope with non-Gregorian calendars, leap
  years, months with different numbers of days, years with different numbers
  of months, etc.  Hint: never try to do the date maths yourself, that's what
  the calendar is there to do for you!
* Add checks for invalid dates
* Always show at least 1 day of previous month.
* Implement method defined in .h but not in .cpp
* Clean up API removing methods and signals no longer needed.
* Prevent a couple of potential memory leaks.
* Add comments, rename locals with more obvious names, no more magic numbers,
  other clean-up stuff to improve readability.
* New CellType of InvalidDate, if cell contains an invalid date then do not
  draw a day number or week number or allow cell to be clicked (goto
  31/12/9999 Gregorian to check).
* Move most of the logic from Calendar to CalendarTable, Calendar is simply a
  frame for the CalendarTable, allows CalendarTable to be re-used in other
  applets for display only (need to add no-click mode for that).
* Move all holiday code from Calendar to CalendarTable where it really belongs
  as is drawing onto the CalendarTable, allows CalendarTable to be reused as a
  static table in other widgets with holidays drawn in but no nav controls
  displayed.
* Use Julian Day number as internal storage key for Holidays rather than ISO
  formatted Gregorian date string as more portable, DataEngine interface not
  changed.

Please also update kdelibs to r981242 which contains a needed fix to the Hijri
and Jalali addMonths() routines.

OK peeps, test away!

CCBUG: 183357


 M  +57 -178   calendar.cpp  
 M  +6 -8      calendar.h  
 M  +237 -155  calendartable.cpp  
 M  +11 -8     calendartable.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=981658