ISO 8601 defines year 0000 in proleptic Gregorian calendar as what is 1 BC. So dates BC represented in ISO 8601 should have year number with absolute value 1 less than in traditional notation. So e.g. the day before 0001-01-01 must be formatted as 0000-12-31. In LO, this is shown as -0001-12-31. To reproduce (e.g., in Calc): 1. Put number -693595 into A1 2. Format as YYYY-MM-DD => "0001-01-01" 3. Put formula `=A1-1` into A2 4. Format as YYYY-MM-DD => "-0001-12-31"
(In reply to Mike Kaganski from comment #0) with: Version 3.6.7.2 (Build ID: e183d5b) Version: 4.4.7.2 result is: 0001-12-31 and with: Version: 5.4.7.2 (x64) Build-ID: c838ef25c16710f8838b1faec480ebba495259d0 CPU-Threads: 4; BS: Windows 6.19; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: single result is: -0001-12-31
Created attachment 157242 [details] test iso date LO 6402 btw: noticed, that opening attached file (created with LO 6402) with LO 4.4.72 will show wrong values: 5535-12-30 5535-12-29
Not having year 0000 is on purpose. For one, there is no year zero in the proleptic Gregorian calendar, see https://en.wikipedia.org/wiki/Year_zero ISO 8601:2004 uses astronomical year numbering, see https://en.wikipedia.org/wiki/Year_zero#ISO_8601 Second, the calendar algorithm is also used to store dates in ODF which is defined with XML Schema Part 2, that has no year 0. Citing from include/tools/date.hxx " Year value 0 is unused. The year before year 1 CE is year 1 BCE, which is the traditional proleptic Gregorian calendar. This is not how ISO 8601:2000 defines things (but ISO 8601:1998 Draft Revision did), but it enables class Date to be used for writing XML files as XML Schema Part 2 in D.3.2 No Year Zero says "The year "0000" is an illegal year value.", see https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#noYearZero and furthermore the note for 3.2.7 dateTime https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#dateTime " If you don't want hell to break loose then don't touch that.. If you want an ISO 8601:2004 compliant calendar then introduce a new calendar in i18npool instead and make it available to number formatting and others. (In reply to Oliver Brinzing from comment #2) > btw: noticed, that opening attached file (created with LO 6402) with LO > 4.4.72 will show wrong values: Of course, BCE Gregorian dates were implemented later for 5.3. Earlier there were several places in the code that couldn't cope with negative years at all.
(In reply to Eike Rathke from comment #3) > If you don't want hell to break loose then don't touch that.. WF. Thanks Eike!
(In reply to Eike Rathke from comment #3) > Earlier there were several places in the code that couldn't cope with > negative years at all. Actually, there are still many places in code (not related to calendar though) that produce ISO 8601 date, not able to cope with full range (though their usage specifics *might* not involve the full range): e.g., makeDateTimeString in forms/source/xforms/xpathlib/xpathlib.cxx; Converter::convert_DateTime2ISO8601 in framework/source/fwi/classes/converter.cxx; utl::toISO8601 in unotools/source/misc/datetime.cxx... Nice redundancy btw ;-D