Guichard Desrosiers created DAFFODIL-3084:
---------------------------------------------
Summary: Calendar code uses ICU EXTENDED_YEAR instead of YEAR,
producing year values that don't conform to the XSD 1.0 spec
Key: DAFFODIL-3084
URL: https://issues.apache.org/jira/browse/DAFFODIL-3084
Project: Daffodil
Issue Type: Bug
Components: Back End
Reporter: Guichard Desrosiers
Daffodil's calendar conversion and comparison code reads the ICU
{{EXTENDED_YEAR}} field for the year value. {{EXTENDED_YEAR}} uses astronomical
(proleptic) numbering — 1 BCE = 0, 2 BCE = -1, etc. — whereas XSD 1.0-year
numbering matches ICU's {{YEAR}} scheme, where 1 BCE = -0001, 2 BCE = -0002,
and there is no year zero. Because the two conventions are offset by one for
all non-positive years, every BCE date Daffodil produces are wrong, and off by
one year. Astronomical year 0 is rendered as the lexically illegal {{{}0000{}}}.
*Proposed Fix:*
Change all uses of {{Calendar.EXTENDED_YEAR}} to {{Calendar.YEAR}} across the
calendar conversion _and_ comparison code, so the lexical year matches XSD1.0
numbering. As a consequence, year 0 is unrepresentable ({{{}YEAR{}}} minimum is
1), which matches XSD 1.0 (no year zero) and structurally guarantees Daffodil
never emits {{{}0000{}}}. ICU under lax rejects a {{0000}} / year-0 lexical
value outright once on {{{}YEAR{}}}. Daffodil should surface this as a *parse
error* (a clean processing-error diagnostic), not an uncaught exception — i.e.
catch ICU's rejection in the calendar parse path and convert it to a normal
Daffodil parse diagnostic.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
