[
https://issues.apache.org/jira/browse/DAFFODIL-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Lawrence resolved DAFFODIL-3077.
--------------------------------------
Fix Version/s: 4.2.0
Resolution: Fixed
Fixed in commit c22dfe85cee2d40bda655f426981b66682d946d6
> 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
> Assignee: Guichard Desrosiers
> Priority: Major
> Fix For: 4.2.0
>
>
> 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)