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) I believe these are 100% equivalent according to ISO8601 which is the standard for date/time referenced from XML/XSD. 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? Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy <http://www.ogf.org/About/abt_policies.php>