I recently fix this issue with adb. please check with a nightly build. there
i used the SimpleDateFormatter to pares the date values correctly with the
time zones.
On 2/16/07, Dennis Sosnoski <[EMAIL PROTECTED]> wrote:
Hi Larry,
You're correct on your assumptions, that if a Calendar is being returned
it should have a consistent time value and time zone. In this case the
time zone of the Calendar should be set to UTC. That said, there are
some seriously warped issues involved - Calendar *always* works with
time zones, while xsd:dateTimes either use UTC times or times with no
zone information (where the latter have basically a half-day uncertainty
factor).
Can you pleas explain this bit? in xml spec the lexical representation of
the datetime is
'-'? yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)? and this
(zzzzz)? part is either be Z (means GMT) or the actual time zone (eg +0530)
xsd:dateTimes do not support time zones in the Java sense at all.
Can't we use the simpleDateFormatter to parse the dates correctly with
timezones?
Dennis can you please check the logic I have used in convertToDateTime
method in org.apache.axis2.databinding.utils.ConverterUtil to parse the
date?
The inappropriate use of Calendar for XML dateTime values in Java is a
long-standing issue that goes back to JAX-RPC days. Calendar just
doesn't work for dateTimes, which is why recent versions of Java have an
added javax.xml.datatype.XMLGregorianCalendar class. Ironically, the
java.util.Date class *is* a direct representation of standard dateTime
values, as long as you don't need sub-millisecond precision - but
because everyone got brainwashed into working with Calendar in Java
that's also what XML code generally uses.
The JiBX data binding support uses java.util.Date as the standard
xsd:dateTime representation, so one solution would be to switch to using
JiBX. I believe the JiBX linkage code generated by WSDL2Java also
handles the xsi:nillable issue properly, only generating this when
allowed by the schema and throwing an exception if a required value is
null.
Aside from that, I suggest you enter bug reports in the Axis2 Jira on
these issues.
- Dennis
Dennis M. Sosnoski
SOA and Web Services in Java
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117
Johnson, Larry D (LJOHNSON) wrote:
>
> I did not specify what platform we are using. We are currently using
> Axis2 v1.1, Java v1.5 and Tomcat 5.5.20.
>
> I have also run a similar test using the .NET framework. The client
> receives a DateTime object from the stubs. On .NET, the value returned
> to the client is correct for the current timezone. This appears to be
> an issue in the generated Java stub classes.
>
> Also, I saw one additional oddity. As reported below, the WSDL
> generated element for the java.util.Date element is as follows:
>
> <xs:element name="departureTime" type="xs:dateTime"/>
>
> Even though I have not specified that this should be a required field,
> it does not have an attribute of nillable="true"; however the SOAP
> message being returned to the client has the form:
>
> <departureTime xmlns:nil="http://www.w3.org/2001/XMLSchema-instance";
> nil:nil="true" />
>
> The nillable attribute is set true here. On the client side, the
> following exception is received:
>
> _java.lang.RuntimeException_: _java.lang.NumberFormatException_
>
> at
> com.arinc.afd.clfengine.client.jl.JLCommandProcessorServiceStub.fromOM
(Unknown
> Source)
>
> at
>
com.arinc.afd.clfengine.client.jl.JLCommandProcessorServiceStub.processLocateBooking
(Unknown
> Source)
>
> at
> com.arinc.afd.jal.webapp.CLFTestClient.jlLocateBooking
(_CLFTestClient.java:101_)
>
> at com.arinc.afd.jal.webapp.CLFTestClient.main(_CLFTestClient.java:315_)
>
> Caused by: _java.lang.NumberFormatException_
>
> at
> org.apache.axis2.databinding.utils.ConverterUtil.convertToDateTime
(_ConverterUtil.java:499_)
>
> at
>
com.arinc.afd.clfengine.client.jl.JLCommandProcessorServiceStub$Flight$Factory.parse
(Unknown
> Source)
>
> Any thoughts?
>
> Regards,
>
> Larry Johnson
>
> ------------------------------------------------------------------------
>
> *From:* Johnson, Larry D (LJOHNSON) [mailto:[EMAIL PROTECTED]
> *Sent:* Thursday, February 15, 2007 11:59 AM
> *To:* axis-user@ws.apache.org
> *Subject:* TimeZone Not Handled Properly In java.util.Date Conversions
>
> It seems the conversions of the java.util.Date class are not being
> handled properly. I have defined a server return value of a
> java.util.Date. The WSDL automatically generated for that value is as
> follows:
>
> <xs:element name="departureTime" type="xs:dateTime"/>
>
> The client stub is generated using the provided WSDL2Java. The client
> stub returns a java.util.Calendar object for this value. So far all is
> well. The problem comes in when you start looking into the handling of
> the TimeZone from server to client. Lets say both client and server
> are within the "Central Standard Time" zone. When the server provides
> the Date object to the POJO interface, the time is
> "1970-01-01T23:55:00.000". Axis2 then converts that time to a GMT
> time. The SOAP message contains "1970-01-02T05:55:00.000Z". Again all
> is well. When the client gets the Calendar object from the stub
> classes, the value is: 01/02/1970 11:55:00 Greenwich Mean Time. The
> time value is incorrect for the TimeZone indicate; however, it is
> correct for the local TimeZone.
>
> The client simply performs the following:
>
> responeData.getDepartureTime();
>
> Am I missing something here? Should the returned Calendar either keep
> the time consistent with GMT or convert the time to local time while
> changing the TimeZone to indicate the local TimeZone?
>
> Regards,
>
> Larry Johnson
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Amila Suriarachchi,
WSO2 Inc.
