[jira] [Commented] (DAFFODIL-2017) Non-portable date/time test_simple_type_properties_text_calendar_13_02

["Josh Adams (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DAFFODIL-2017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757360#comment-16757360 ] 

Josh Adams commented on DAFFODIL-2017:
--------------------------------------

So I dug through the spec and as far as I can tell, both approaches are technically allowed.  Here are the only hard set rules I found that seemed to deal with this:

The number of fractional second digits supported is implementation-defined but must be
at least millisecond accuracy.

and

When unparsing and the time zone is UTC, the time zone is output as ‘+00:00’

 

That being said, on the tests where IBM is failing, they are using calendar patterns that do not include timezones or fractional seconds.  I believe we specifically implemented things in Daffodil to not include timezone/fractional seconds in the infoset if they are not actually being used, which to me seems like the more appropriate behavior.  That being said, I understand if we want to make sure our output can match the IBM version.

> Non-portable date/time test_simple_type_properties_text_calendar_13_02
> ----------------------------------------------------------------------
>
>                 Key: DAFFODIL-2017
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-2017
>             Project: Daffodil
>          Issue Type: Bug
>          Components: Back End, Compatibility
>    Affects Versions: 2.2.0
>            Reporter: Michael Beckerle
>            Assignee: Josh Adams
>            Priority: Major
>              Labels: ForInteroperabilityTest
>
> Ran under IBM DFDL. The test failed.
> Differences are 
> * IBM uses "Z" where Daffodil uses "+00:00"
> * IBM shows "000" for fractional seconds where Daffodil does not
> Question is: which one is correct and why. If "both" behaviors are "allowed", then we likely need a switch in Daffodil to prefer the same behavior as IBM DFDL, vs. staying with the current behavior (which we still need to preserve for existing users.)
> Here's the output when running on IBM DFDL.
> {{org.apache.daffodil.tdml.TDMLExceptionImpl: (Implementation: ibm) 
> Comparison failed.
> Expected
>           <calendar_group><date1>2010-12-30+00:00</date1><time1>04:05:06+01:00</time1><datetime1>2010-12-30T04:05:06+00:00</datetime1></calendar_group>
> Actual
>           <calendar_group><date1>2010-12-30Z</date1><time1>04:05:06.000+01:00</time1><datetime1>2010-12-30T04:05:06.000Z</datetime1></calendar_group>
> Differences were (path, expected, actual):
>  (calendar_group/date1,'2010-12-30+00:00','2010-12-30Z')
> (calendar_group/time1,'04:05:06+01:00','04:05:06.000+01:00')
> (calendar_group/datetime1,'2010-12-30T04:05:06+00:00','2010-12-30T04:05:06.000Z')}}
> The same issues arise for these tests:
> test_simple_type_properties_text_calendar_13_03
> test_simple_type_properties_text_calendar_13_04
> test_simple_type_properties_bin_calendar_13_01
> test_simple_type_properties_bin_calendar_13_02
> test_length_delimited_12_01
> test_length_delimited_12_02
> 	
> These tests originated with IBM (a LONG time ago), though it's possible we changed them to match Daffodil behavior if we thought the behavior was correct the way we changed it. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)