You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by ge...@ws.apache.org on 2005/03/15 15:54:34 UTC
[Apache Web Services Wiki] Updated: FrontPage/Axis/DotNetInterop
Date: 2005-03-15T06:54:34
Editor: DinoChiesa
Wiki: Apache Web Services Wiki
Page: FrontPage/Axis/DotNetInterop
URL: http://wiki.apache.org/ws/FrontPage/Axis/DotNetInterop
no comment
Change Log:
------------------------------------------------------------------------------
@@ -7,9 +7,12 @@
'''Q: What about transferring java.util.Calendar values?'''
-A: There are known problems with serializing/deserializing Calendar objects. 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.
+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.
+
+Another possible workaround is to specify the value as type xsd:date, which does not carry a timezone.
-Two possible work arounds are the use of a string or wrapper value object. When transmitting time values, a long of time in seconds (classic C time_t) is recommended.
'''Q: Can you provide mappings for Java datatypes to their equivalents under .NET?'''