stevedlawrence commented on code in PR #1685:
URL: https://github.com/apache/daffodil/pull/1685#discussion_r3436564868
##########
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:
Yeah, I think that behavior is fine. The XMLGregorianCalendar exception
becoming a TDML error is reasonable because a failure there indicates an
expected infoset in a parserTestCase that is invalid, so it's more of an
incorrectly written TDML file than a parse/unparse error, so TDMLException
makes sense. We often use that for indicating there is something wrong with a
TDML file.
Yeah, we would need to write a unit test since tdml tests can't expect
TDMLExceptions. We have a number of unit tests that do
`intercept[TDMLException]` so there is precedent for this kind of thing.
--
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]
