gdesrosiers1805 commented on code in PR #1685:
URL: https://github.com/apache/daffodil/pull/1685#discussion_r3433159710
##########
daffodil-core/src/main/scala/org/apache/daffodil/lib/calendar/DFDLCalendarConversion.scala:
##########
@@ -95,7 +98,16 @@ object DFDLCalendarConversion {
val d = string.substring(endYear + 4, endYear + 6)
try {
- calendar.set(Calendar.EXTENDED_YEAR, Integer.parseInt(y))
+ // Use YEAR + ERA rather than EXTENDED_YEAR to match XSD 1.0 numbering:
+ // a negative lexical year is BCE, stored as ERA=BC with positive YEAR.
+ val yInt = Integer.parseInt(y)
+ if (yInt < 0) {
Review Comment:
In practice, `yInt` can never be `0` unless the value somehow bypasses ICU
entirely.
From my investigation and tracing, the raw document string first comes in
through `ConvertTextCalendarParser.parse`. For example, consider the date
`0000-01-01T23:00:00` with the explicit pattern:`uuuu-MM-dd'T'HH:mm:ss`
When ICU parses that text via `df.parse(txt, cal, pos)`, it sets: `YEAR = 1`
and `ERA = BC` on the calendar instance. Later,
`DFDLCalendarConversion.datePartToXMLString` renders that calendar value as:
`-0001-01-01`
So by the time the string reaches `datePartFromXMLString`, the date has
already been transformed from:
`0000-01-01T23:00:00` to `-0001-01-01T23:00:00`. So ICU has already
normalized year zero to `-0001` (1 BC). As a result, `yInt` can never be `0` on
this code path.
It is possible to intentionally specify year `0000` in an expected infoset,
but that follows a different code path. In that case, the value is validated by
`dateTimeIsSame`, which uses the new `XMLGregorianCalendar` for the comparison.
Since year `0000` is not valid under XSD 1.0, the comparison ultimately throws
a `TDMLException`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
