Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 1.4.7
-
Fix Version/s: 1.4.8
-
Component/s: Converters
-
Labels:None
-
JDK version and platform:Oracle 1.7 for Windows
Description
We have recently been experiencing issues deserialising XML with specific time zones. This only seems to be occurring on Windows where the time zone does not have an Id that is in the available list of Ids. It seems this is caused by Windows not using the Olson time zone database.
For example, when setting the system time zone to GMT-12:00 and calling TimeZone.getDefault().getID() the JRE will return "GMT-12:00". Joda time knows about this and if you try and use this to convert to a Joda DateTimeZone it will strip of the "GMT" prefix and return a time zone with Id of "-12:00".
The problem seems to be in com.thoughtworks.xstream.converters.extended.ISO8601GregorianCalendarConverter.fromString(String). This has the following code:
... String timeZoneID = TimeZone.getDefault().getID(); for (int i = 0; i < formattersNoUTC.length; i++ ) { try { DateTimeFormatter formatter = formattersNoUTC[i].withZone(DateTimeZone.forID(timeZoneID)); ... } ... } ...
This code is getting the time zone Id from the JRE and then passing this to DateTimeZone.forID to convert to a Joda time zone. This doesn't work when the time zone Id is not in the available list of Ids. There is an invalid assumption that the same time zone Id from the JRE can be used to get the Joda time zone.
There is actually no need to even use the Id here, the code could simply be:
... final DateTimeZone dtz = DateTimeZone.getDefault(); for (int i = 0; i < formattersNoUTC.length; i++ ) { try { DateTimeFormatter formatter = formattersNoUTC[i].withZone(dtz); ... } ... } ...
This ignores the problem entirely and uses the time zone reported by Joda directly.
Activity
Field | Original Value | New Value |
---|---|---|
Description |
We have recently been experiencing issues deserialising XML with specific time zones. This only seems to be occurring on Windows where the time zone does not have an Id that is in the available list of Ids. It seems this is caused by Windows not using the Olson time zone database.
For example, when setting the system time zone to GMT-12:00 and calling {{TimeZone.getDefault().getID()}} the JRE will return "GMT-12:00". Joda time knows about this and if you try and use this to convert to a Joda DateTimeZone it will strip of the "GMT" prefix and return a time zone with Id of "-12:00". The problem seems to be in {{com.thoughtworks.xstream.converters.extended.ISO8601GregorianCalendarConverter.fromString(String)}}ââ¬â¹. This has the following code: {code} ... String timeZoneID = TimeZone.getDefault().getID(); for (int i = 0; i < formattersNoUTC.length; i++ ) { try { DateTimeFormatter formatter = formattersNoUTC[i].withZone(DateTimeZone.forID(timeZoneID)); ... } ... } ... {code} This code is getting the time zone Id from the JRE and then passing this to {{DateTimeZone.forID}} to convert to a Joda time zone. This doesn't work when the time zone Id is not in the available list of Ids. There is an invalid assumption that the same time zone Id from the JRE can be used to get the Joda time zone. There is actually no need to even use the Id here, the code could simply be: {code} ... final DateTimeZone dtz = DateTimeZone.getDefault(); for (int i = 0; i < formattersNoUTC.length; i++ ) { try { DateTimeFormatter formatter = formattersNoUTC[i].withZone(dtz); ... } ... } ... {code} This ignores the problem entirely and uses the time zone reported by Joda directly. |
We have recently been experiencing issues deserialising XML with specific time zones. This only seems to be occurring on Windows where the time zone does not have an Id that is in the available list of Ids. It seems this is caused by Windows not using the Olson time zone database.
For example, when setting the system time zone to GMT-12:00 and calling {{TimeZone.getDefault().getID()}} the JRE will return "GMT-12:00". Joda time knows about this and if you try and use this to convert to a Joda DateTimeZone it will strip of the "GMT" prefix and return a time zone with Id of "-12:00". The problem seems to be in {{com.thoughtworks.xstream.converters.extended.ISO8601GregorianCalendarConverter.fromString(String)}}. This has the following code: {code} ... String timeZoneID = TimeZone.getDefault().getID(); for (int i = 0; i < formattersNoUTC.length; i++ ) { try { DateTimeFormatter formatter = formattersNoUTC[i].withZone(DateTimeZone.forID(timeZoneID)); ... } ... } ... {code} This code is getting the time zone Id from the JRE and then passing this to {{DateTimeZone.forID}} to convert to a Joda time zone. This doesn't work when the time zone Id is not in the available list of Ids. There is an invalid assumption that the same time zone Id from the JRE can be used to get the Joda time zone. There is actually no need to even use the Id here, the code could simply be: {code} ... final DateTimeZone dtz = DateTimeZone.getDefault(); for (int i = 0; i < formattersNoUTC.length; i++ ) { try { DateTimeFormatter formatter = formattersNoUTC[i].withZone(dtz); ... } ... } ... {code} This ignores the problem entirely and uses the time zone reported by Joda directly. |
Resolution | Fixed [ 1 ] | |
Fix Version/s | 1.4.x Maintenance [ 19602 ] | |
Status | Open [ 1 ] | Resolved [ 5 ] |
Fix Version/s | 1.4.x Maintenance [ 19602 ] | |
Fix Version/s | 1.4.8 [ 20992 ] |
Status | Resolved [ 5 ] | Closed [ 6 ] |
Well, as soon I apply your proposed change, we have a failing unit test. Problem is, that DateTimeZone.getDefault() does not (and cannot) take into account if a user changed the default of the Java runtime using TimeZone.setDefault("CEST").
However, we have an additional problem since Java 6, because since this runtime version we have localized time zone abbreviations. E.g. with a German default locale we get MESZ (Mittel-Europäische SommerZeit) instead of CEST (Central European Summer Time). What a mess!