https://bugs.freedesktop.org/show_bug.cgi?id=40575
--- Comment #17 from Eike Rathke <[email protected]> --- I think changing the internal representation in tools' class Date wouldn't be that hard. To inspect places that might rely on the internal layout of Date::nDate and do calculations on their own and if so fix them to use proper class Date methods, I'd make the following methods private and global make to catch where it breaks: Date( sal_uInt32 _nDate ) void SetDate( sal_uInt32 nNewDate ) sal_uInt32 GetDate() const Using css::util::Date would only have advantage over improving tools' Date internals for that it would obsolete the internal back/forth conversion to/from coded integer. Its year field is a short, thus sal_Int16 with a max year value of 32765 which would be less than the 214748 years. (not that I don't doubt any use if such year values anyway ;-) How you actually represent a date in an application is a different goal, and the spreadsheet applications' way (and not only those) to express a date/time as a double since a null date is yet something different. This is also independent of how you format a date, and the formatter doesn't have to care what the Date class uses internally. I agree that the sal_uIntPtr should be sal_Int64 instead. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
