[Libreoffice-bugs] [Bug 152381] sal_Int32 comphelper::date::YearToDays(sal_Int16): Assertion `nYear != 0' failed.
https://bugs.documentfoundation.org/show_bug.cgi?id=152381 Eike Rathke changed: What|Removed |Added Status|NEW |ASSIGNED OS|Linux (All) |All Assignee|libreoffice-b...@lists.free |er...@redhat.com |desktop.org | Hardware|x86-64 (AMD64) |All -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152381] sal_Int32 comphelper::date::YearToDays(sal_Int16): Assertion `nYear != 0' failed.
https://bugs.documentfoundation.org/show_bug.cgi?id=152381 --- Comment #2 from Eike Rathke --- Sure, if code sets/uses a date with year 0 (or even day=0,month=0,year=0 in this case) for the proleptic Gregorian calendar then that code is wrong ;-) That so far didn't matter because the Base code had its own and wrong conversion. Problem here seems to be a NULL value of the database that is *not* a date to be converted to relative days, entering connectivity/source/commontools/dbconversion.cxx dbtools::DBTypeConversion::toDouble() with _rVal all 0 then via dbtools::DBTypeConversion::toDays() dbtools::implRelativeToAbsoluteNull() calls the now new comphelper::date::convertDateToDaysNormalizing() that via its calls asserts. The old dbtools::implRelativeToAbsoluteNull() implementation for day=0,month=0,year=0 returned -365 for that "date", which is completely off. Whatever the old now eliminated dbtools::implBuildFromRelative() did for such.. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152381] sal_Int32 comphelper::date::YearToDays(sal_Int16): Assertion `nYear != 0' failed.
https://bugs.documentfoundation.org/show_bug.cgi?id=152381 Julien Nabet changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=15 ||2386 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152381] sal_Int32 comphelper::date::YearToDays(sal_Int16): Assertion `nYear != 0' failed.
https://bugs.documentfoundation.org/show_bug.cgi?id=152381 Julien Nabet changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||er...@redhat.com, ||serval2...@yahoo.fr Ever confirmed|0 |1 --- Comment #1 from Julien Nabet --- On pc Debian x86-64 with master sources updated today, I could reproduce this too. I also noticed this: 52ff16771ac160d27fd7beb78a4cfba22ad84f06 Resolves: tdf#152114 Use comphelper::date algorithms ... that can actually cope with negative (BCE) proleptic Gregorian calendar dates, which already for Julian calendar dates 0001-01-01 and 0001-01-02 they are. (2022-11-22) Eike: any thoughts here? -- You are receiving this mail because: You are the assignee for the bug.
