XSD *does* specify, but it's often ignored by XML processing code. The
issue is that XSD includes a "time zone" only as an offset from
Universal Time - an adjustment to the time value, in other words - but
the tools often try to turn this offset into a true time zone. This
violates the XSD specification and leads to all kinds of problems with
DST and such.
What an xsd:dateTime value represents is the equivalent of a
java.util.Date instance - an instant in time, with no associated time
zone. JAXB converts it to a java.util.Calendar, which also works fine if
the Calendar is set to UTC. It sounds like the Calendar is instead being
set to some other time zone.
- Dennis
Malachi de AElfweald wrote:
>Very odd, because Client and Server are on the same machine...
>
>Is this a bug in the XSD spec? Is there no way to specify?
>
>This is a real problem, because since we are writing a remote task manager
>for a customer, having the wrong time is a show stopper. We can't sell a
>task manager if it fails to schedule tasks on time.
>
>Malachi
>
>
>On Tue, 26 Aug 2003 12:37:07 +1200, Pete Hendry
><peter.hendry_at_capeclear.com> wrote:
>
>
>
>>You'll find the problem will come back. It's a daylight savings problem
>>and will happen during a certain time period. I can't remember the
>>specifics but it's because there is no DST information on the wire and
>>the Calendar created during deserialization will pick up the setting of
>>the current machine. Either the serializer is not taking account of DST
>>when it works out the timezone offset or the deserializer is not
>>resetting the timezone not to use DST I think.
>>
>>I looked at this a long time ago with our implementation. It's a horrible
>>problem.
>>
>>Pete
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net