Summary: | Bug in calendarmonth: October 1582 | ||
---|---|---|---|
Product: | [Frameworks and Libraries] kdelibs | Reporter: | Thomas Kamps <progger1986> |
Component: | kdeui | Assignee: | John Layt <jlayt> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | jlayt, mail, mboquien |
Priority: | LO | ||
Version: | 4.1 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Thomas Kamps
2008-10-16 19:25:09 UTC
I can reproduce the bug. Confirmed. That's a KDatePicker bug, reassigning. I still wonder how you noticed that :D OK, I'm guessing that the KDateTable::posFromDate() and KDateTable::dateFromPos() routines are too naive in their calculations, they just do maths on the number of cells rather than finding out the day numbers of the cells and doing the maths on those. That's fine for every other month in every other pure calendar system, but October 1582 is the switchover from Julian to Gregorian in Qt's weird hybrid calendar system and so we throw away 10 days in-between. I'll look at a fix, but don't expect too high a priority for it :-) In 4.2.1 the problem got worse: October 1582 goes from 1 to 21 If you select one date from 5 to 14. the calendar jumps to year 0 Trying this in 4.3 rc1 in the Plasma calendar and KDatePicker it appears the bug has been resolved? I suspect a bugfix in Qt perhaps solved it. Can people test and see if there are any issues around this date. Current behaviour: If October 1582 is selected: OK If one of the days 5...14 is selected you cannot access October 1582 But the named bug is fixed :) |