Details
-
Type:
Bug
-
Status:
Closed
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.2.2
-
Component/s: None
-
Labels:None
-
JDK version and platform:JDK 1.6
Description
I have an object on my server with has dates. The date on the server are java.util.Date. They are from a database that stores the dates in LA time (GMT-8). I marshal the object with XStream and send it to the client program which unmarshals it back into the object. The client's timezone is not GMT-8 but any other (such as GMT, GMT-3, etc).
When doing Date.toString () or DateFormat.format (Date), the date is shown without timezone conversion. Upon inspection, I found that on the server, the date is correctly flagged as being in GMT-8. However, on the client, it is marked as being in the current timezone - which it isn't.
It seems that when the date marshalled, it looses its timezone information.
Expected behavior is that the date, when shown using Dateformat.format (Date) would be shown in the user's locale - i.e., if it was 1:00AM GMT-8, when shown on a client in GMT, it would show 9:00AM.
Hi Etienne,
date handling is somewhat complicated. First of all you have to recognize, that a Date does not have any information about the time zone. The data kept within a Date object must always be interpreted in combination with a time zone (therefore the Calendar was introduced, which combines date and time zone). When XStream marshals a date value to a String it saves therefore string representation of the date as it is interpreted in the current time zone. And since the time zone meanwhile might have changed it also stores the time zone itself. Therefore XStream is able to unmarshal the Date object and return a date that corresponds to the saved time - but now in the current time zone.
However, I found a bug. While a Date object has no information about the time zone, the DateFormat has! The format uses the time zone of its first usage. Since XStream pools the DateFormat instances and they are reused, they did not respect a later change in the time zone. This is fixed in subversion now.
Please give it a try. If it does not work for you, please use the mailing list to demonstrate the problem. From your description I was not sure, what you really did. If you still have a problem and it manifests as bug, we can reopen this issue.
BTW: You noticed that you can register also the ISO8601 converters to use a unified date format?