dfdl:calendarTimeZone issue

[Mike Beckerle <mb...@tresys.com>]

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?

Re: dfdl:calendarTimeZone issue

[Steve Lawrence <sl...@apache.org>]

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?
> 
>