I have a case where IBM DFDL and Daffodil differ, but I think both are correct so this is just a case where users have to tolerate variation in behavior:

<dfdl:format calendarPatternKind="implicit"  calendarTimeZone="UTC" />

<xs:element name="date1" type="xs:date" />

The data is "2010-12-30"

The DFDL spec says the parser behavior is as for pattern "yyyy-MM-dd", which does not have any character for time zone information.

So the time zone information is coming from the dfdl:calendarTimeZone="UTC" property.

But this question isn't about the parsing/unparsing behavior. It's about what date/time components end up in the infoset and how those get projected into XML by different DFDL implementations.

The problem is that there are multiple equivalent (according to XML/XSD and ISO 8601) representations in the infoset for this information.

Ex:

     <date1>2010-12-30+00:00</date1> (Note: current Daffodil behavior)

or

     <date1>2010-12-30Z</date1> (Note: current IBM DFDL behavior)

If this is acceptable then there's no action here. It's just an equivalence that users have to expect.

So I'm just raising this to get opinions.

Comments?