Submitted by Dennis Sosnoski, entered by Joe Fialli.
There is an incompatibility between the Java and XML Schema concept
of timezone that impacts javax.xml.datatype.XMLGregorianCalendar.
The Java concept of timezone provides for daylight savings time to enter
into Calendar operations.
Extracted from java.util.TimeZone javadoc.
- TimeZone represents a time zone offset, and also figures out daylight savings.
- No daylight saving time transition schedule can be specified with a custom
time zone ID.
The XML Schema representation of timezone is only in UTC and there is no
means to represent a daylight savings timezone in XML format nor to compensate
for daylight savings transitions in calendar computations.
Dennis suggests that to keep this clear to the users the setTimeZone method
of XMLGregorianCalendar should be specified to allow only constant time
zones and should throw a runtime exception if the user tries to set a
time zone that incorporates daylight saving time transitions.
Another suggestion in the expert group is that the data representation should
not incorporate the XML Schema restriction, only the act of marshalling
an instance of XMLGregorianCalendar to XML native format should normalize
the value to lose its daylight savings transition schedule.
Here is an example of how daylight savings transition schedule impacts
an operation.
If one adds 6 months to a dateTime with a time of 6:00 and the Java representation
for timezone has a daylight savings transition schedule, the time will be
either one hour less or more of the original 6:00. However, if the Java
representation
did not have a daylight savings timezone, no change would occur.
All instances of XMLGregorianCalendar that are unmarshalled from XML content
could never have a daylight savings timezone, since there is no way to represent
this info in XML Schema. However, instances of XMLGregorianCalendar created
within a Java application by a user, could easily have a daylight savings timezone,
especially if the default timezone is a daylight savings timezone. Supporting
Dennis' proposal, JAXB has a requirement to be able to marshal from Java to
XMl and back to Java and have the two Java representations be identical.
If the original Java calendar had a daylight savings timezone, there is no
way to preserve this in the roundtrip from Java to XML to Java again.
It can be potentially confusing to have the behavior of adding 6 months
work differently based on whether the XMLGregorianCalendar was created in
the Java application vs unmarshalled from XML content.
The following needs to be reflected in the comparison operations on
XMLGregorianCalendar.
The comparison of dateTime values is specified that two dateTimes are equal if
- they both have time zones and the normalized (UTC) values are the same
- are both in unknown time zones with the same values.
Environment
Operating System: All
Platform: All
Affected Versions
[2.0 draft]