The backwards incompatibility doesn't concern me too much. It's pretty minor, and the dates are still effectively the same. Also long as we make sure to include it in the "backwards compatability" section in releases note.
However, does this also affect xs:time and xs:dateTime types? What happens to the time zone part of those types if we switch from "UTC" to empty value? If there is no timezone in the data, is it left off in the infoset like with xs:date, or does it do something else like use the timezone of the local machine? If it leaves it off, that's consistent with xs:date and seems fine, but if it does something like use the local timezone, that might be a bigger backwards incompatible change. - Steve On 04/25/2018 07:09 PM, Mike Beckerle wrote: > So in DFDLGeneralFormat.dfdl.xsd, which is built-in to Daffodil, there is a > binding for dfdl:calendarTimeZone="UTC". > > > That seems ok, but if you import a date like "07/04/1999" you get an XML date > like: > > 1999-07-04+00:00 > > > That is, you get a UTC time zone specifier on any date. > > > This is really undesirable in that it is unexpected. Perhaps the value for > dfdl:calendarTimeZone should be "" (empty string), meaning no time zone > assumed. Changing that results in the right behavior in the XML infoset > > of 1999-07-04, which is what people expect. > > > Only issue is changing this is, technically, incompatible backward. > > > But the alternative is every schema where dates are used, where the timezone > isn't supposed to be specified, is going to have to override the default of > "UTC" with "" by itself. > > > Thoughts? > >
