Version: (using KDE KDE 3.5.4) Installed from: Fedora RPMs OS: Linux The implementation of the above functions is problematic on non-Gregorian calendars. All the implementations take 1/1/1753 relative year as minimum, and 1/1/8000 relative year as maximum. Sources: Hebrew http://developer.kde.org/documentation/library/3.5-api/kdelibs-apidocs/kdecore/html/kcalendarsystemhebrew_8cpp-source.html#l00515 Hijri http://developer.kde.org/documentation/library/3.5-api/kdelibs-apidocs/kdecore/html/kcalendarsystemhijri_8cpp-source.html#l00511 Jalali http://developer.kde.org/documentation/library/3.5-api/kdelibs-apidocs/kdecore/html/kcalendarsystemjalali_8cpp-source.html#l00519 Now, let's say that 1/1/1753 is in the middle of the relative year (very likely to happen) - the beginning of the "valid" year is actually invalid, because it is before 1/1/1753. The same goes for 1/1/8000. If daysInYear(1/1/8000) is more than 365, then the days after the 365th day are invalid too, and this year should be valid! To solve this, these functions need to be changed in all decendants (KCalendarSystemHebrew, KCalendarSystemHijri and KCalendarSystemJalali) to return year(1/1/1753) + 1 and year(1/1/8000) - 1.
product should be kdelibs, not kde. sorry for that.
This bug should now be closed. This will not be resolved in KDE3, but KDE4 has replaced minValidYear and maxValidYear with earliestValidDate and latestValidDate which will return the full date, not just the year (see patch 691586). And as a bonus, the valid date range is being extended to cover from the range 1/1/1 to (initially) the last day of 9999 in each calendar system (Gregorian will start in 4713BC Julian). John.
On second thoughts, this is a bug we can fix, assign to me to work on.
I think it's safe to say this will never be fixed in KDE3 now, better to face reality and close the bug.