[
https://issues.apache.org/jira/browse/DAFFODIL-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guichard Desrosiers reassigned DAFFODIL-3084:
---------------------------------------------
Assignee: Guichard Desrosiers
> 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
> Assignee: Guichard Desrosiers
> Priority: Major
>
> 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)
