RE: [castor-dev] How to suppress TimeZone offset when Marshalling java.util.date

[Andrew Fawcett]

Hi Stephen,   You can set the TimeZone used by Castor XML when handling java.util.Date's.   By calling the static org.exolab.castor.xml.handlers.DateFieldHandler.setDefaultTimeZone method.   You carn't stop it outping the timezone offset, but you can have it use Z for UTC timezone.   DateFieldHandler.setDefaultTimeZone(TimeZone.getTimeZone( UTC_TIMEZONE ));   Hope this helps you!   Cheers   From: Stephen Burrows [mailto:[EMAIL PROTECTED] Sent: 08 April 2005 13:36 To: 'dev@castor.codehaus.org' Subject: [castor-dev] How to suppress TimeZone offset when Marshalling java.util.date   Hi All,   Does anyone know of a way to suppress timeZone offsets when marshalling a java.util.Date.   We unmarshall the following field   <dlx:FlightSegment DepartureDateTime="2005-06-04T11:45:00.000" ArrivalDateTime="2005-06-03T22:30:00.000+01:00" ResBookDesigCode="Y" RPH="0" FlightNumber="9566" NumberInParty="1">   Then marshall back and the castor marshaller adds the daylight saving timezone offset of +01:00 to the DepartureDateTime field.   <dlx:FlightSegment DepartureDateTime="2005-06-04T11:45:00.000+01:00" ArrivalDateTime="2005-06-03T22:30:00.000+01:00" ResBookDesigCode="Y" RPH="0" FlightNumber="9566" NumberInParty="1">   This causes problems when we pass messages between machines in different timezones , as the marshaller Adjusts the timezone accordingly and  changes the time   Example below > Request from time zone A: > <dlx:FlightSegment DepartureDateTime="2005-06-04T11:45:00.000+01:00" > ArrivalDateTime="2005-06-03T22:30:00.000+01:00" ResBookDesigCode="Y" > RPH="0" FlightNumber="9566" NumberInParty="1">   > Server Response from time zone B: > <ns2:FlightSegment DepartureDateTime="2005-06-04T20:45:00.000+10:00" > ArrivalDateTime="2005-06-04T07:30:00.000+10:00" ResBookDesigCode="Y" > RPH="0" FlightNumber="9566" NumberInParty="1">   DepartureDateTime has changed L   Any suggestions.?   Regards,   Stephen Burrows   The information in this message is confidential and may be legally privileged. It may not be disclosed to, or used by, anyone other than the addressee. If you receive this message in error, please advise us immediately. Internet emails are not necessarily secure. CODA does not accept responsibility for changes to any email which occur after the email has been sent. Attachments to this email may contain software viruses, which could damage your systems. CODA has checked the attachments for viruses before sending, but you should virus-check them before opening.