Affects Version/s: 1.4.4
Fix Version/s: 1.4.5
JDK version and platform:Oracle jdk1.7.0_21 for Mac OS X 10.8.4
As of JDK 7, the default locale supports categories. This enables the separation between display and format locales.
I have my system set to English, but use German number and date formats (Basically, everything is english, but the calendar format and style is german, i.e. monday is the first day of the week instead of sunday etc).
The constructor of GregorianCalendar uses Locale.getDefault(Locale.Category.FORMAT) internally to create a calendar, whereas the ISO8601GregorianCalendarConverter uses Locale.getDefault().
On my system, those two differ and therefore, the calendar returned by the converter is created with a different locale than a regular new Calendar(â¦) would create. And due to the weird implementation of date handling in Java, those two are not equal (Calendar equality is locale dependent).
I would expect two calendars, one created by xstream and one via new GregorianCalendar(â¦) to be equal and consider their inequality to be a bug.
I've created a failing unit test as well.
I assume a fix should be straight forward - it would however probably break JDK6 compatibility. Still, I'd be glad if you could fix it in an upcoming release.
Calling DateTime.getGregorianCalendar() instead now. This is not affected, because it let internally use the Java runtime select the Locale on its own. Fixed in HEAD. Thanks for the test case, though.
By the way. My current and probably permanent workaround is to simply ditch Calendar & co and just use JodaTime instead...