The xsd:timeDate format is specified in the XML Schema Part 2: Datatypes specification, in Appendix D [1]. It's based on ISO 8601.
Per the JAX-RPC spec, xsd:timeDate should map to java.util.Calendar rather than String. [1] http://www.w3.org/TR/xmlschema-2/#isoformats Anne -----Original Message----- From: Zach Hensley [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 27, 2004 3:51 PM To: [EMAIL PROTECTED] Subject: xs:timeDate to Calendar Object It appears as though that there is no clear definition in any spec, be it JAX-RPC, or WSDL, as to how xs:timeDate should be formatted. I am using axis 1.1 release, and my client will not necessarily be a java client. As a result I think that there is an inefficiency in the wsdl2Java generation. The client try's to parse the String with the getLocaDateTimeInstance() via the String constructor yet the server returns a Calendar.toString() representation of the dateTime instance. If I am correct I only see the following options as a solution. 1. Override the Gregorian.toString() method and return the default DateFormat and hope that the client is using the same locale. 2. Change the type from xs:dateTime to String and enforce the format constraints on the server side, or in the schema. Will Axis recognize regular expressions in the schema, that would probably be the best option. 3. Change the type class so that it will always use the same format. This would mean that the client would have to use an already defined/non-generated type class though. Any comments are greatly appreciated. Whether I am missing something or if there is a solution that I have not seen, or just some random comment is fine too. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.667 / Virus Database: 429 - Release Date: 4/23/2004
