3

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...

mezoid
  • 28,090
  • 37
  • 107
  • 148

2 Answers2

2

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:

  • Java dates are GMT plus an offset
  • Axis seems to pass the date to .Net without the offset information.
  • .Net then assumes local time for a time that is actually GMT...which leads to offset problems of +/-24 hours.

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...

mezoid
  • 28,090
  • 37
  • 107
  • 148
0

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.

jtahlborn
  • 52,909
  • 5
  • 76
  • 118
  • I've updated my answer with the results I get when I look at the timezone info in .net and java. – mezoid Apr 11 '11 at 01:36