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
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.