Version: unknown (using 4.4.00 (KDE 4.4.0), Gentoo) Compiler: x86_64-pc-linux-gnu-gcc OS: Linux (x86_64) release 2.6.32-gentoo-r5 What a funny bug! My mom is born on Feb 1961, the 19th. However, using the birthday kresource, korganizer says she will have 48 this year! If I look in 2009, the age computation is correct (48) and in 2013 too (52) but, for the years 2010, 2011 and 2012, there is always one year less. If I change the birth month to April, the bug is still here. If I change the birth year (I tried 1902 and 1988), the bug disappears. My mom will be very happy not becoming older this year, but, well, I would be happy that this bug apply to every birth year to have this gift too ;-)
Oh, this bug also occurs for me! I'm born on April 1985, the 11th, and korganizer says I will still have 24 this year. The calculation remains wrong if I set my birth year to 1984. The calculation is correct if I set my birth year to 1983 or 1986, 1987.
The problem lies in the following code: qint64 KOHelper::yearDiff( const QDate &start, const QDate &end ) { return static_cast<qint64>( start.daysTo( end ) / 365.25 ); } In case 1 above this gives ( 19 Feb 2010 - 19 Feb 1961 ) / 365.25 = ( 2455246 - 2437349 ) / 365.25 = 17897 / 365.25 = 48.9993 = 48 When obviously it should be 49. you could add a few more days on to the end date to fix the rounding, or do it properly: if ( end.month() > start.month() || ( end.month() == start.month() && end.day() > start.day() ) { end.year() - start.year(); } else { end.year() - start.year() - 1; } I should probably provide KCalendarSystem methods to do this. This assumes a standard rule for date maths that if the end month has fewer days than the start month you move to the last day of the same month. So a birthday on the 29th Feb will be moved to 28th Feb, which is the law in the UK. I think KOrganizer follows the day of year rule, i.e. always falls on day 60 so would be 1st March in non-leap years, which would be wrong in the UK context at least. Don't even get me started on rules for moving Hebrew birthdays, those rules blow my mind :-) Also it doesn't localise the calendar system either, but that seems widespread throughout KOrganizer, there's a lot of inconsistencies as a result if the user has a non-Gregorian system calendar selected. Perhaps KO should always force to run in Gregorian for now, especially as iCalendar only supports Gregorian?
Whoops, small typo, should be "end.day() >= start.day()". It also assumes start < end, it needs tweaking for start >= end (i.e. same year or how many years ago something happened).
*** Bug 228523 has been marked as a duplicate of this bug. ***
*** Bug 228924 has been marked as a duplicate of this bug. ***
I should note my alogrithm above is slightly wrong, I'll post a correct version to Reviewboard soon.
*** Bug 232662 has been marked as a duplicate of this bug. ***
I've watched the same with a birthday of 13-Apr-1940 => 69years!?? to 13-Apr-2010. I would suggest to round the result of KOHelper::yearDiff(). And I would suggest to display the original date in the preview window of kontact/calendar. My version: kde/kontact/calendar-4.4.2 (kubuntu)
I also have this problem with a friend born 1980-05-02 and displaying in korganizer going to have 29 years old instead of 30 onother one born on 1985-02-01 displaying having 24 instead of 25 while another born on 1976-02-01 is rightly displayed as having 34 years old
*** This bug has been confirmed by popular vote. ***
*** Bug 235254 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > The problem lies in the following code: > > qint64 KOHelper::yearDiff( const QDate &start, const QDate &end ) > { > return static_cast<qint64>( start.daysTo( end ) / 365.25 ); > } The correct code should actually be: qint64 KOHelper::yearDiff( const QDate &start, const QDate &end ) { return static_cast<qint64>( (start.daysTo( end ) + 1) / 365.25 ); } This is a common mistake when doing time/date related maths.
*** Bug 236704 has been marked as a duplicate of this bug. ***
is there a chance that this bug is removed soon ?
My brother, born in 1990, also triggers this issue (KDE 4.4.2). Looks rather silly, to be honest ;-)
Oh no, what a mess! The calendar year's length is 365.2425 since 1582. The rounding method is chosen wrongly (I'd suggest round to nearest by adding 0.5), affecting everybody in my list of birthdays. Worst of all, this is even using QDate, which has a year function. Just use end.year()-start.year() for printing out the years for birthday and anniversary, and be done! No need for helper function for something that trivial, and even then possibly to mess it up. QDate has its own problems, by (wrongly) stating that there is "no year 0". Yes, there is, and it's there for 10 years now, it is all very handy for computer-related date calculation. Read up the ISO 8601 standard about date and time representations, or at lest http://de.wikipedia.org/wiki/ISO_8601. And please have someone with checking rights to KDE take this bug, it can't be more than a five minutes fix.
all the age calculations are wrong by me - Kubuntu 10.04 Lucid Lynx.
It would be helpful. please, to get a progress report. Are there any remaining tasks that can be handed off to users/bug reporters? The more qualified among us seem to have provided code suggestions. Are these inadequate? Is that all will be revealed in KDE 4.5? The silence is a bit deafening.
This is such a visible bug, and is really harmful to the reputation of kde. Is there a purpose in submitting bug reports if no one seems to read them?
this was fixed a couple days ago and will be included in the next 4.4.x release
Thank you very much for the good news :)