I believe JAXB uses the default (Calendar.getInstance()), which would be
your local time zone.
So, the problem is that it is assuming PST and never PDT.
I think you are right about the UTC option. If JAXB switched to ALWAYS use
the UTC TimeZone, I don't think it would break anything (as long as both
Client and Server are using JAXB -- perhaps it might break something if
not)...
So, I propose the following:
JAXB provide two methods. Say it currently does:
setTime(Calendar cal)
instead do:
setTime(Calendar cal) <-- which calls setTime(cal, true);
setTime(Calendar cal, boolean useUTC) <-- specifies which
Calendar.getInstance() to use
On the local machine, when get call getTime() and it returns a UTC
Calendar, it is not going to foul anything up. I just did the following
test (results inlined as comments)....
import java.util.*;
public class zoneTest
{
public static void main(String[] args)
{
try{
Calendar here = Calendar.getInstance();
TimeZone localTimeZone = TimeZone.getDefault()
;//.getTimeZone("America/Los_Angeles");
Calendar local = Calendar.getInstance(localTimeZone);
TimeZone utcTimeZone = TimeZone.getTimeZone("UTC");
Calendar utc = Calendar.getInstance(utcTimeZone);
Calendar derived = Calendar.getInstance(utcTimeZone);
derived.setTimeZone(localTimeZone);
System.out.println ("here: " + here.getTime() + "\t/" +
here.get(Calendar.HOUR));
System.out.println ("local: " + local.getTime() + "\t/" +
here.get(Calendar.HOUR));
System.out.println ("utc: " + utc.getTime() + "\t/" +
here.get(Calendar.HOUR));
System.out.println ("derived: " + derived.getTime() + "\t/" +
here.get(Calendar.HOUR));
/**
* OUTPUT:
here: Tue Aug 26 05:30:24 PDT 2003 /5
local: Tue Aug 26 05:30:24 PDT 2003 /5
utc: Tue Aug 26 05:30:24 PDT 2003 /5
derived: Tue Aug 26 05:30:24 PDT 2003 /5
*/
}catch (Exception e) {
System.out.println("Exception: " + e.getMessage());
e.printStackTrace();
}
}
}
On Mon, 25 Aug 2003 22:39:20 -0700, Dennis Sosnoski <dms_at_sosnoski.com>
wrote:
> 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
>
>
>
--
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net