Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.
The following page has been changed by JasonCone: http://wiki.apache.org/ws/FrontPage/Axis/DotNetInterop ------------------------------------------------------------------------------ A: This works, although there are some things you have to look out for. Under Java, the [http://java.sun.com/j2se/1.4.2/docs/api/java/util/Calendar.html Calendar] class includes timezone information. Under .NET, the [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemDateTimeClassTopic.asp System.DateTime] structure does not contain timezone information. The .NET Framework assumes its timezone is the current timezone when serializing and ignores it when deserializing. As a result, values can be off by +/- 24 hours. - One possible workaround is to assume any time or date to be UTC. This means you have to use [http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemDateTimeClassToUniversalTimeTopic.asp ToUniversalTime()] method on the .NET side when sending times or dates, and you must also correctly parse the time/date strings originating from the Java side. + Previously, this page has advised that one possible workaround is to assume any time or date to be UTC (i.e. use [http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemDateTimeClassToUniversalTimeTopic.asp ToUniversalTime()] method on the .NET side when sending times or dates, and correctly parse the time/date strings originating from the Java side). However, such an approach will not work due to the way .NET serializes the DateTime object. The .NET XML serializer always assumes that the DateTime values being serialized represent local machine time, so it applies the machine local time zone offset as the offset portion of the encoded XML. See [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/datetimecode.asp this article] for more details. + + Because the .NET XML serializer encodes the DateTime correctly *only* if the DateTime represents the local machine time, the easiest approach is to send the local time in the DateTime, and send the time zone/offset along with it in a separate variable. Another possible workaround is to specify the value in WSDL as type xsd:date, which does not carry a timezone. This works only if you use WSDL First (more about that below).
