Version: Unbekannt (using 4.1.2 (KDE 4.1.2) "release 45.1", KDE:KDE4:Factory:Desktop / openSUSE_11.0) Compiler: gcc OS: Linux (i686) release 2.6.25.16-0.1-my Open with a clock-plasmoid a calender. Go to October 1852. There will be 21 days shown. That is correct. When you click on the 15.10.1582 the 25.20.1582 will be marked. Analog with the other days past the 4.10.1582. Clicking oh 16 marks 26, and so on.
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 :)