Home/ Questions/Q 6672701
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T03:32:21+00:00

I’ve written a JAX-WS webservice in Java by generating a WSDL and classes from

  • 0

I’ve written a JAX-WS webservice in Java by generating a WSDL and classes from an XML schema.

I am adding the service as a web reference in visual studio, to use with a C#.NET client application.

The original XML schema uses a couple of date/time types: xs:date and xs:dateTime for some of the elements.

My problem is that my ‘dateTime’ type is not working correctly. It is converted to a .NET DateTime object (correctly) in the generated classes (produced by XMLSerializer in Visual Studio 2010), and then I can create my own DateTime object and set the DateTime on one of these classes. However when sending the request back to the server, the client application is sending a null value instead of the DateTime object I set it to. So I guess it is not serializing correctly.

I do not have the same problem with the ‘date’ type, which serializes/deserializes fine.

I noticed something which could be the problem, but not sure:

The dateTime object in the generated class looks like this:

[System.Xml.Serialization.XmlElementAttribute(Order=10)]
public System.DateTime MyDateTime { ... }

whereas the date object in the generated class looks like this:

[System.Xml.Serialization.XmlElementAttribute(DataType="date", Order=12)]
public System.DateTime MyDate { ... }

So, there is some additional info in the date object – DataType=”date”, but there is no DateType for the dateTime object. Could this be the problem? If so, why is it not generating the classes correctly?

Thanks for any help

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I have ran into this problem before and after a lot of hard work I found one end of the communication was using a UK (dd/MM/yyyy) Date format and the other was using a US (MM/dd/yyyy) format. This is set in globalization culture on the machine ( like the answer from @Gaurav ) however, the following wasn’t so obvious:

    when I ran my code under VS I run as myself and therefore my own culture of en-GB. As you may know when I run the code under IIS it is run under the ASPNET account (or NETWORK SERVICE, etc depending on the version of IIS). It turns out that the ASPNET account has a culture of en-US, hence the problem.

    The simple solution is to add a globalisation tag to the Web.config and set the culture and uiculture attributes.

    • 0