dateTme.iso8601

[ajay.aggarwal]

Without enabling the extensions, is there a way to correctly map my
"java.util.Date" java type to a true "ISO8601" value? As mentioned on
this page (http://ws.apache.org/xmlrpc/types.html) when the
java.util.Date field gets sent on the wire, its missing the important
timezone information. And as a result the other side (which I don't have
control over) thinks I am off by 4 hours. The other side also does not
understand extensions. So enabling extensions is not an option.

 

Any other clever workaround/suggestion from folks who might have already
dealt with this issue?

 

Is there a way to override XML mapping for "java.util.Date" class ?

 

Thanks.

 

-Ajay

[Jochen Wiedmann]

On Thu, Aug 13, 2009 at 11:50 PM, Aggarwal,
Ajay<Ajay.Aggarwal@...> wrote:

> Without enabling the extensions, is there a way to correctly map my
> "java.util.Date" java type to a true "ISO8601" value?

Not in a manner, which is compliant to the XML-RPC spec. That's
because the SPEC doesn't permit timezones and the like.

Of course, you are free to violate the SPEC by introducting a custom
data type handler. See the section on "Custom Data Types" on
    http://ws.apache.org/xmlrpc/advanced.html


Jochen


--
Base64 decoding, 300% faster than sun.misc.BASE64Decoder:
http://archive.netbsd.se/?ml=commons-dev&a=2008-05&t=7522166

[tugwilson]

On 13 Aug 2009, at 22:50, Aggarwal, Ajay wrote:

> Without enabling the extensions, is there a way to correctly map my
> "java.util.Date" java type to a true "ISO8601" value? As mentioned on
> this page (http://ws.apache.org/xmlrpc/types.html) when the
> java.util.Date field gets sent on the wire, its missing the important
> timezone information. And as a result the other side (which I don't  
> have
> control over) thinks I am off by 4 hours. The other side also does not
> understand extensions. So enabling extensions is not an option.
>
>
>
> Any other clever workaround/suggestion from folks who might have  
> already
> dealt with this issue?
>

As Jochen has said, the spec does not allow the sending of timezone  
information.

The safest option is to use the timezone of the other end when sending  
and receiving time data. If you violate the spec then you may not get  
support from the people running the service if you have problems.

John Wilson

[ajay.aggarwal]

Thanks John and Jochen for your suggestions. Unfortunately the other
side interprets the SPECs differently and thinks that timezone
information is OK to be part of time data. I think I may try custom data
handler.

-Ajay

-----Original Message-----
From: John Wilson [mailto:tug@...]
Sent: Friday, August 14, 2009 2:50 AM
To: xmlrpc-dev@...
Subject: Re: dateTme.iso8601


On 13 Aug 2009, at 22:50, Aggarwal, Ajay wrote:

> Without enabling the extensions, is there a way to correctly map my
> "java.util.Date" java type to a true "ISO8601" value? As mentioned on
> this page (http://ws.apache.org/xmlrpc/types.html) when the
> java.util.Date field gets sent on the wire, its missing the important
> timezone information. And as a result the other side (which I don't  
> have
> control over) thinks I am off by 4 hours. The other side also does not
> understand extensions. So enabling extensions is not an option.
>
>
>
> Any other clever workaround/suggestion from folks who might have  
> already
> dealt with this issue?
>

As Jochen has said, the spec does not allow the sending of timezone  
information.

The safest option is to use the timezone of the other end when sending  
and receiving time data. If you violate the spec then you may not get  
support from the people running the service if you have problems.

John Wilson