Description: from Calc .. dates sequence is ok ... nothing from 14 to 05 oct but functions year(),month() and day() return wrong values DATE YEAR MONTH DAY 16/10/1582 1582 10 16 15/10/1582 1582 10 15 04/10/1582 1582 10 14 03/10/1582 1582 10 13 02/10/1582 1582 10 12 01/10/1582 1582 10 11 30/09/1582 1582 10 10 29/09/1582 1582 10 9 28/09/1582 1582 10 8 27/09/1582 1582 10 7 26/09/1582 1582 10 6 30/12/1482 1483 1 8 Steps to Reproduce: see above Actual Results: see above Expected Results: obvious Reproducible: Always User Profile Reset: No Additional Info: Version: 7.3.2.2 (x64) / LibreOffice Community Build ID: 49f2b1bff42cfccbd8f788c8dc32c1c309559be0 CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: fr-FR (pt_BR); UI: pt-BR Calc: threaded
YEAR, MONTH and DAY functions calculate as if the Gregorian calendar is in use, the DATE functions returns an error, and implicit conversions (like done by formatting the serial number as date) is local, epoch dependent. It is up to the user to decide whether a function is usable for his use case. But we should extend the help about the use of Gregorian calendar so that the user can know about the behavior.
Excuse me ... I did not catch everything you wrote ! :( Could you explain better please ? In my point of view, no function should return a wrong value, in any case. If there is a range of date the function return a right value, out of the range should raise an error condition. Other way it is a bug. day, month and year functions return a wrong value for "1482-12-30" ... it should return a right value or an error message. Philippe
*** This bug has been marked as a duplicate of bug 144678 ***
(In reply to raal from comment #3) > *** This bug has been marked as a duplicate of bug 144678 *** Or rather, of bug 144692 - and they all have a common bug 144699, which needs ODF clarification to be resolved. *** This bug has been marked as a duplicate of bug 144692 ***
*** This bug has been marked as a duplicate of bug 122158 ***