Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.3.1
-
Fix Version/s: 1.4
-
Component/s: Converters
-
Labels:None
Description
The serialized Dates created by the standard DateConverter have ambiguous 3-letter timezones. This may result in wrong dates when the data deserialized under a different default timezone than the timezone they were serialized in.
DateConverter uses the datetime pattern "yyyy-MM-dd HH:mm:ss.S z" which creates ambiguous 3-letter timezones (e.g. EST). When e.g. a date is serialized in Australian eastern time (EST) and deserialized in Amerian eastern time (also EST), the timestamp changes!
Test case:
String pattern = "yyyy-MM-dd HH:mm:ss.S z";
TimeZone.setDefault(TimeZone.getTimeZone("Australia/Brisbane"));
Date date = new Date(0);
System.out.println(date.getTime());
String s = new SimpleDateFormat(pattern).format(date);
System.out.println(s);
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
System.out.println(new SimpleDateFormat(pattern).parse(s).getTime());
prints:
0
1970-01-01 10:00:00.0 EST
54000000
Activity
Hi Christoph,
a) Use the UTC+/-x format to format timezones. I.e. "yyyy-MM-dd HH:mm:ss.S Z". This has the potential disadvantage that one maybe cannot e.g. determine if UTC+02:00 refers to Central European Summer Time or Eastern European Time. However, much better than the current behaviour anyway
Unfortunately we cannot. XStream 1.x is JDK 1.3 compatible still and "Z" is not available in 1.3.
b) Save all dates in UTC time (or Unix timestamp) and just convert it into the default local timezone when deserializing. This drops all timezone information associated with the date, but as it seems that the timezone cannot be reconstructed reliably anyway, this is maybe the better way.
I think this is the way to go. I'll probably create a ctor for the DateConverter to define the TZ used for serialization. UTC will be used by default then, but it is still possible to enable the old behavior. The nice thing is, that the deserialization is independent of this and the old dates are still correctly deserialized (well, as long as the TZ is unambiguous).
Note that the 'long' timezones (i.e. "yyyy-MM-dd HH:mm:ss.S zzzz") doesn't seem to be any better as just 'z' in this respect. At least they make no difference in the testcase above.
I recognized that also. Even while the long format identifies EST as Australian time, this info is not used. But the worse effect of this is that the long string is localized.
Jörg Schaible
added a comment - Hi Christoph,
a) Use the UTC+/-x format to format timezones. I.e. "yyyy-MM-dd HH:mm:ss.S Z". This has the potential disadvantage that one maybe cannot e.g. determine if UTC+02:00 refers to Central European Summer Time or Eastern European Time. However, much better than the current behaviour anyway
Unfortunately we cannot. XStream 1.x is JDK 1.3 compatible still and "Z" is not available in 1.3.
b) Save all dates in UTC time (or Unix timestamp) and just convert it into the default local timezone when deserializing. This drops all timezone information associated with the date, but as it seems that the timezone cannot be reconstructed reliably anyway, this is maybe the better way.
I think this is the way to go. I'll probably create a ctor for the DateConverter to define the TZ used for serialization. UTC will be used by default then, but it is still possible to enable the old behavior. The nice thing is, that the deserialization is independent of this and the old dates are still correctly deserialized (well, as long as the TZ is unambiguous).
Note that the 'long' timezones (i.e. "yyyy-MM-dd HH:mm:ss.S zzzz") doesn't seem to be any better as just 'z' in this respect. At least they make no difference in the testcase above.
I recognized that also. Even while the long format identifies EST as Australian time, this info is not used. But the worse effect of this is that the long string is localized. Fixed in head revision.
Jörg Schaible
added a comment - Fixed in head revision. 
I could think of the following types of solution:
a) Use the UTC+/-x format to format timezones. I.e. "yyyy-MM-dd HH:mm:ss.S Z". This has the potential disadvantage that one maybe cannot e.g. determine if UTC+02:00 refers to Central European Summer Time or Eastern European Time. However, much better than the current behaviour anyway
b) Save all dates in UTC time (or Unix timestamp) and just convert it into the default local timezone when deserializing. This drops all timezone information associated with the date, but as it seems that the timezone cannot be reconstructed reliably anyway, this is maybe the better way.
Note that the 'long' timezones (i.e. "yyyy-MM-dd HH:mm:ss.S zzzz") doesn't seem to be any better as just 'z' in this respect. At least they make no difference in the testcase above.