Reputation: 28730
I'm trying to call a .Net webservice from Java. I have a java.sql.Date that I am converting to a Calendar which then gets passed through to .Net as a DateTime.
Unfortunately, when it gets to the other side it is a day behind the date that was sent. This is a known issue as per (http://wiki.apache.org/ws/FrontPage/Axis/DotNetInterop) and I'm sure there is a way around it but I just can't seem to find it.
Does anyone know of a way to correctly convert a java.sql.Date to a Calendar so that there is no 24 hour offset issue?
The code I have at the moment is as follows:
java.sql.Date myDate = Date.valueOf("2011-04-11");
Calendar calendarDate = Calendar.getInstance();
calendarDate.clear();
calendarDate.setTime(myDate); //we then pass calendarDate off to webservice...
When I look at the timezone info I see the following:
In Java the following gets me "Eastern Standard Time (New South Wales)":
calendarDate.getTimeZone().getDisplayName();
In .Net the following gets me "AUS Eastern Standard Time":
TimeZone.CurrentTimeZone.StandardName;
As far as I am currently aware, both Java and .Net have the local time in the same timezone...
Upvotes: 3
Views: 2398
Reputation: 28730
I'm not sure if this is the correct thing to do...but it seems to have fixed my problem...
java.sql.Date myDate = Date.valueOf("2011-04-11");
Calendar calendarDate = Calendar.getInstance();
//normalise the SQL date
//http://download.oracle.com/javase/6/docs/api/java/sql/Date.html
calendarDate.set(Calendar.HOUR_OF_DAY, 0);
calendarDate.set(Calendar.MINUTE, 0);
calendarDate.set(Calendar.SECOND, 0);
calendarDate.set(Calendar.MILLISECOND, 0);
calendarDate.setTime(myDate);
calendarDate.set(Calendar.DST_OFFSET, 0); //Clear the daylight savings offset
calendarDate.set(Calendar.ZONE_OFFSET, 0); //Clear the timezone offset
Setting the offset to zero seems to allow it to avoid the offset issue altogether.
I think this works because the Java and .Net webservices seem to interact like this:
I think my fix of setting the offset to zero after setting the date causes the Calendar to keep the date consistent with local time in the absence of the offset. Thus when the date gets to the .Net webservice the assumption of local time is correct.
I have no idea if that is the case or not and would appreciate a better explanation...but for now, unless told otherwise, this solution appears to work...
Upvotes: 2
Reputation: 53694
according to that article, .net always handles dates in the local timezone (wow, is that broken). so, you must determine the timezone of the .net service and set that timezone on your Calendar instance.
Upvotes: 0