Bug 154016 - KCalendarSystem incorrectly calculates last Week Number in 1BC as -1, causes crashes and lockups
Summary: KCalendarSystem incorrectly calculates last Week Number in 1BC as -1, causes ...
Status: RESOLVED FIXED
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: kdecore (show other bugs)
Version: 4.0
Platform: Compiled Sources Linux
: NOR crash
Target Milestone: ---
Assignee: John Layt
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-12-14 11:20 UTC by Shawn Starr
Modified: 2009-08-06 09:41 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Picture of error (35.22 KB, image/png)
2007-12-14 11:21 UTC, Shawn Starr
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Shawn Starr 2007-12-14 11:20:20 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources
Compiler:          gcc version 4.2.3 20071123 (prerelease) (Debian 4.2.2-4) 
OS:                Linux

In plasma, the digital clock applet/plasmoid now has a KDatePicker widget, I was just playing around by looking at Year 1 (1 AD) when I selected the week combobox, It showed 'Week -1 *'

Attached is picture
Comment 1 Shawn Starr 2007-12-14 11:21:09 UTC
Created attachment 22539 [details]
Picture of error

Picture of error showing the weird result from Plasma digital clock applet
Comment 2 John Layt 2007-12-15 17:51:57 UTC
The combobox should be showing week 52 or 53 of year 1BC, obviously the maths in the routine is not quite right when crossing the non-existant year 0 divide, it will probably need a special case added to the routine.  I'll look at this when I get back next week.

In the bug title, you state it crashes apps but provide no further details.  Could you detail this further and provide backtraces?
Comment 3 John Layt 2008-06-07 00:02:40 UTC
Bug probably lies in KCalendarSystem::weekNumber() so set component to kdecore, update title, cc to me.
Comment 4 John Layt 2009-06-28 18:22:58 UTC
There is a problem in the addMonths() and addYears() methods that doesn't cater for there being no year 0 in the Julian/Gregorian calendar that would be contributing to this, but doesn't fully resolve it.  Will commit as soon as 4.3 is out the door and open to bug-fixes again.
Comment 5 John Layt 2009-07-06 16:40:31 UTC
SVN commit 992292 by jlayt:

Fix the Y0K bug

The Julian/Gregorian Calendar does not have a Year 0, so all maths on a year
needs to adjust for this when moveing over the BC/AD divide.  A new private
method addYearNumber() does this correctly and should be used in all parts
of the code that needs to add years.

The Hebrew, Hijri and Jalali calendars are unaffected by this as none of our
implementations are proleptic, i.e. allow dates before year 1.

In 4.4 when we get calendar systems that do have a Year 0 we will need to
modify the addYearNumber() method to repect this.

Leave bug open for now as will need to backport to 4.3 once released.

CCBUG: 154016



 M  +50 -21    kcalendarsystem.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=992292
Comment 6 John Layt 2009-07-06 16:45:32 UTC
I found a few more places to fix and this fix fully resolves the issue.
Comment 7 John Layt 2009-08-06 09:41:29 UTC
SVN commit 1007713 by jlayt:

Fix the Y0K bug.  Backport commit 992292 from trunk.

The Julian/Gregorian Calendar does not have a Year 0, so all maths on a year
needs to adjust for this when moving over the BC/AD divide.  A new private
method addYearNumber() does this correctly and should be used in all parts
of the code that needs to add years.

The Hebrew, Hijri and Jalali calendars are unaffected by this as none of our
implementations are proleptic, i.e. allow dates before year 1.

In 4.4 when we get calendar systems that do have a Year 0 we will need to
modify the addYearNumber() method to repect this.

BUG: 154016



 M  +50 -21    kcalendarsystem.cpp  


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