Details
-
Type:
Improvement
-
Status:
Closed
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.1
-
Component/s: None
-
Labels:None
Description
ISO 8601 formats cannot be parsed using the current SimpleDateFormat solution used in the standard DateConverter.
ISO 8601 is the standard format for dates represented in XML (when declared in an XSD as a datetime), so this is fairly important. In fact, it is required if communicating with other "strict" XML-based systems.
The "jigsaw" webserver by W3C.org contains a class with static methods to parse and create ISO8601 dates (org.w3c.util.DateParser). This was easy to include into the XStream codebase - I have it working locally on my machine, but this needs to be properly integrated into XStream.
Activity
I don't think it's that simple, since most of the fields are optional - you can remove fields (starting from the right) and get less-and-less accurate datetime values, and it's still a valid date, right up to just having the year field left ("2004" is a valid date, ust like that!) Also, there is all the timezone correction fields which have to be taken into account (or not, if they are omitted). Complicated stuff.
James Schopp
added a comment - I don't think it's that simple, since most of the fields are optional - you can remove fields (starting from the right) and get less-and-less accurate datetime values, and it's still a valid date, right up to just having the year field left ("2004" is a valid date, ust like that!) Also, there is all the timezone correction fields which have to be taken into account (or not, if they are omitted). Complicated stuff. Not only should the XML Schema date format be used exclusively for dates, they should also only be represented in UTC, and not as currently, the default timezone. Since the timezone is not part of the java.util.Date class, it makes the date unusable unless the timezone is predictable.
Nils Kilden-Pedersen
added a comment - Not only should the XML Schema date format be used exclusively for dates, they should also only be represented in UTC, and not as currently, the default timezone. Since the timezone is not part of the java.util.Date class, it makes the date unusable unless the timezone is predictable. I've added an ISO8601DateConverter based on http://joda-time.sf.net.
It under extended converters, as we don't want to have the joda dependency to be mandatory.
Joe, we could check at runtime if joda-time is classpath and register
the ISO8601DateConverter or the basic DateConverter.
How does that sound?
Mauro Talevi
added a comment - I've added an ISO8601DateConverter based on http://joda-time.sf.net .
It under extended converters, as we don't want to have the joda dependency to be mandatory.
Joe, we could check at runtime if joda-time is classpath and register
the ISO8601DateConverter or the basic DateConverter.
How does that sound? This sounds good to me (it let's me get rid of my custom patches on top the standard code!).
Still, it'd be nice to have some standard "DefaultConverter" config/property file that I could override, instead of being tied to what is compiled into the standard build.
James Schopp
added a comment - This sounds good to me (it let's me get rid of my custom patches on top the standard code!).
Still, it'd be nice to have some standard "DefaultConverter" config/property file that I could override, instead of being tied to what is compiled into the standard build. For the moment, we'll leave it the user to register the
ISO8601DateConverter if he needs it.
xstream.registerConverter(new ISO8601DateConverter())
will override the default DateConverter for type Date.
The reason why it is not registered automatically is
to prevent problems in distributed systems in which
one side has the joda-time in the classpath and the
other doesn't.
Mauro Talevi
added a comment - For the moment, we'll leave it the user to register the
ISO8601DateConverter if he needs it.
xstream.registerConverter(new ISO8601DateConverter())
will override the default DateConverter for type Date.
The reason why it is not registered automatically is
to prevent problems in distributed systems in which
one side has the joda-time in the classpath and the
other doesn't. 
I think it's just a matter of adding a new dateformat: "yyyy-MM-dd'T'HH:mm:ss"
Does that sound right?