You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-dev@ws.apache.org by "Aggarwal, Ajay" <Aj...@stratus.com> on 2009/08/13 23:50:27 UTC
dateTme.iso8601
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
RE: dateTme.iso8601
Posted by "Aggarwal, Ajay" <Aj...@stratus.com>.
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@wilson.co.uk]
Sent: Friday, August 14, 2009 2:50 AM
To: xmlrpc-dev@ws.apache.org
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
Re: dateTme.iso8601
Posted by John Wilson <tu...@wilson.co.uk>.
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
Re: dateTme.iso8601
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Thu, Aug 13, 2009 at 11:50 PM, Aggarwal,
Ajay<Aj...@stratus.com> 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