Amila,
I have just downloaded the Axis2 v1.1.1-SNAPSHOT version and installed it. This version has the same issue. Regards, Larry Johnson ________________________________ From: Amila Suriarachchi [mailto:[EMAIL PROTECTED] Sent: Thursday, February 15, 2007 11:48 PM To: [email protected] Subject: Re: TimeZone Not Handled Properly In java.util.Date Conversions 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(U nknown > Source) > > at > com.arinc.afd.clfengine.client.jl.JLCommandProcessorServiceStub.processL ocateBooking(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$F actory.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:* [email protected] > *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.
