[ 
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)

Reply via email to