Bug in ISO8601GregorianCalendarConverter

[Grauel, Moritz]

Hi,

I've found a very subtle, yet annoying bug in the locale handling of ISO8601GregorianCalendarConverter.

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) to create a calendar, whereas your converter 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 break JDK6 compatibility. Still, I'd be glad if you could fix it in an upcoming release.

Regards and thanks,
Moritz

Some more Details:

OS: Mac OS X 10.8.4
JDK: Oracle jdk1.7.0_21

[Jörg Schaible]

Hallo Moritz,

Post by Grauel, Moritz
Hi,
I've found a very subtle, yet annoying bug in the locale handling of
ISO8601GregorianCalendarConverter.
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) to create a calendar, whereas
your converter 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 break JDK6
compatibility. Still, I'd be glad if you could fix it in an upcoming
release.

Can you please open a JIRA ticket and append the unit test there? Then we
can track the issue and it will not get lost.

Thanks a lot,
Jörg