I am having the following problem, while sending Date through WebServices.
In the application which has been assigned to me, I call a WebService (from the presentation-tier server) to update contact details (which include date-of-birth of type java.util.Date). The presentation-tier server and the backend-server (where the WebService is running) are in different time zones. Now when I send the date (set in the contact object), its going as the date/time in the time zone of presentation-tier server, and when I receive the same in backend server, its coming as date/time in the time zone of backend server. Because of this change in time zone, the records getting saved are having improper data. The WSDL has xsd ateTimeas the type for date-of-birth.
I must say that, its a bad design to send date over the WebService. But at this point of time I have no other option and the design can't be changed.
Any fix/suggestion to overcome this issue will be highly appreciated.
I see you can specify a timezone while still matching the xsd:DateTime type. Have you tried that?
(In my opinion the "bad design" is in forcing a date to be a timestamp. There are numerous business applications where we have a date without a time component. Date of birth is just one example.)
posted 12 years ago
The issue is with timezone only. Even if I specify (or not specify) timezone, the date is going as a date in the local time zone where the WebService client is running and is received in the local time zone where the WebService is runnig.
I want to avoid the timezone thing, as this is affecting the date which is eventually getting saved in database. Now for date-of-birth since only the date needs to displayed/updated, because of the timezone issue while passing date through webservice, there's a difference in the date displayed after saving it.
The point is that the timezone is a part of a date/time.
xsd:dateTime follows ISO-8601 conventions. If the timezone is not specified, it is assumed to be in the local time zone (in your case the time zone of the backend) - so then the local timezone is added before it is sent out - then the presentation server "localizes" the date to its own timezone.
Basically you have to realize that your "date-of-birth" isn't a date in the xsd:dateTime sense. So the easiest way to deal with it is to send a "date-of-birth" xsd:string.