- Posted by: Dupont Martin
- Posted on: January 04 2006 13:42 EST
The JSR 109 or JAX-RPC doesn't guarantee timezone conservation when calling a web service accepting a xsd:dateTime parameter. So how can we manage a web service accepting a date of birth parameter ? (if the client has a different timezone than the server, he will use his own timezone, my server will use his own timezone when deserializing and I will have sometimes a different date of birth - one day more or less).
Is there a well known solution to this (really basic) problem ?
- Should I use a string parameter instead of a xsd:dateTime one (don't like at first this solution since everyone can format the date as he wants).
- Should I ask the client to send an xsd:dateTime with GMT timezone (don't like it cause the client developper will never read the documentation).
- Is there something else ?
Here's a link on this mapping limitation :
Here's another one explaining the problem and a solution (urk !) :
Thanks very much for your help
This timezone problem is clearly a limitation of the JAX-RPC specs (the mapping info in this specs is quite empty, they say Calendar and Date map to xsd:dateTime, but not how the mapping must be done -> so every app server can implement it its own way).
Good point for web services interoperability (don't know how much money was spent in it, but it's rather silly).
So here are the different options for solving this problem (I think I'm going for option 1) :
1. use custom types (i.e. XMLDate with an xs:string with the xsd:date format).
public class XMLDate
public String get/setValue (String)
This class will only contain year, month and day info.
Since the custom XML type will be mapped to a standard javabean class (value type), we don't need custom serializers.
The problem is that both the web service client and I will need to write a customer serializer to transform XMLDate to a plain java Calendar type.
I'm going to enumerate all basic classes having the same problem (timezone info), or a related problem and create new XML types.
2. always assume GMT timezone info. This solution is error prone.
3. Use a javabean encapsulating timezone info and the xsd:dateTime value, i.e. :