suppressing time zone when printing an xsd:date - Weblogic

>The following change seems to suppress the time zone:
>
> Calendar calendar =3D new GregorianCalendar();
> calendar.set(1972, Calendar.AUGUST, 29);
> calendar.clear(Calendar.ZONE_OFFSET);
> purchaseOrder.setOrderDate(calendar);
>
>When output, orderDate no longer has a time zone:
>
> <purchaseOrder orderDate=3D"1972-08-29">
>
>I have two questions:
>
>1. Are there any dangers to clearing the time zone like this?
>Any danger of rolling forward to the next day accidentally
>around 5 hours from midnight. :-)
>
>2. Is this the preferred method of suppressing time zones?
>Are there other techniques (perhaps using
>xsetOrderDate(XmlDate)) that would be shorter, safer,
>or otherwise preferred?

XML date types can withstand absence of information such as time zone, but =
you
need to be aware that GregorianCalendar really cannot (even though it looks=
like
it can), and certainly java.util.Date cannot.

When translating from a timezone-free XML schema date to a standard Java ob=
ject,
eventually you will get to a point when a timezone will be filled in. When =
this
happens, the system's current locale time zone is used. Usually this is ju=
st
fine, and will not result in a date rollover as long as you print out the d=
ate
in the current locale's time zone as well.

One thing you need to be aware of is the fact that even though it looks lik=
e you
can clear the timezone information from it, GregorianCalendar is on a hair-=
trigger
to fill in cleared (unset) fields. So as soon as you call some getters to =
look
at a few other fields, you'll probably find that the time-zone is set again=
(to
the local time zone). [In fact, as part of extracting the information from=
GregorianCalendar
when you call the setter, we probably will have caused the timezone to be s=
et
- try it.]

XmlBeans ships with two classes to help with this situation:

(1) XmlCalendar is a subclass of GregorianCalendar that stably maintains th=
e set
of unset fields. As long as you only access already-filled-in-fields, it d=
oesn't
try to recompute and fill in unset fields. Whenever you "get" a Calendar o=
bject
in XmlBeans, we return an XmlCalendar so that you get an object with nice s=
table
properties. So if you supply an XmlCalendar to the setter, the timezone wi=
ll
remain unset.

(2) GDate is an object that very precisely implements the concept of an XML=
Schema
date. GDate can be precisely converted to and from XmlCalendar, and it can=
be
used to do schema-compliant date arithmetic. That's really only important =
if
you're adding schema durations or comparing dates to each other and you wan=
t to
apply the precise schema rules. (The validator uses GDate internally.)

My summary: what you're doing is fine and safe, but I'd probably use XmlCal=
endar
rather than a plain GregorianCalendar.

cheers,

David