Steve Lawrence created DAFFODIL-3077:
----------------------------------------
Summary: XMLUtils comparison relies on specific ICU versions
Key: DAFFODIL-3077
URL: https://issues.apache.org/jira/browse/DAFFODIL-3077
Project: Daffodil
Issue Type: Bug
Components: TDML Runner
Affects Versions: 4.1.0
Reporter: Steve Lawrence
The XMLUtils compareAndReport calls the textIsSame function to do type-aware
comparison when xsi:type is defined. However, if xsi:type is
xs:date/time/dateTime, then we use the
DFDLDate/Time/DateTimeConversion.fromXMLString function to convert the infoset
string to an object for equality comparison.
However, these date/time converters create and use ICU objects. This can cause
issues when trying to test with the IBM DFDL cross tester, which depend on an
older version of ICU. For example, the conversters can call "Calendar.clone()",
which is only available in newer ICU versions.
Some potential options:
# Rewrite the calendar conversion classes to only use functions that are
compatible with older versions of ICU. IBM DFDL uses ICU 51.1, so we should at
least support that so we can continue cross testing
# Rewrite TDML date/time comparison using the java.time package. The supported
patterns are fairly limited and do not require ICU complexities
# Simplfy date/time type comparisons with custom logic. I believe the only
differences we have ever seen with date times is in extra sub-second decimal
point precision (e.g. 1.234000 vs 1.234). It's possible there could be other
differences (e.g. timezones), but one could argue that timezone information is
important and so should not be canonicalized in the infoset and that two
date/times with different timezones should never be considered the same. We
could add custom parsing logic to the TDML Runner to ignore these trailing
sub-second zeros as long as we confirm the trailing zeros are part of the
sub-seconds part of a time/dateTime.
Note that this is potentially more important once DAFFODIL-182 is fixed, which
enables xsi:type and thus could allow for more type-aware comparisons.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)