3

I am integrating with a web service (i dont have control to this web service) using wsdl provided. While calling a method, i need to pass DateTime in request. The request needs to contain datetime in UTC format (with Z in the end). The request contains below field, 

[System.Xml.Serialization.XmlElementAttribute(DataType="date", Order=0)]
public System.DateTime date
{
   get
    {
       return this.dateField;
     }
    set
    {
    this.dateField = value;
  }

Please note the xsd datatype is a date.

I construct the request to pass DateTime as Utc, 

request.date = DateTime.SpecifyKind(DateTime.Parse(DateTime.Now.ToUniversalTime().ToString("yyyy'-'MM'-'dd'T'HH':'mm':'ss'.'fff'Z'")), DateTimeKind.Utc);

The problem i have is even though i pass DateTime as Utc, the soap request appears without the time zone. For eg, the request gets generated as shown below,

           <GetRequest xmlns=" http://soa.company.com/services/example/v2"> 
              <date>2001-01-01</date> 
           </GetRequest>

My expectation is to get,

           <GetRequest xmlns=" http://soa.company.com/services/example/v2"> 
              <date>2001-01-01Z</date> 
           </GetRequest>

I think this is due to roundtrip during datetime serialization. Has anybody faced this kind of issue?

John Saunders
  • 160,644
  • 26
  • 247
  • 397
Rajee
  • 272
  • 2
  • 8
  • I have edited your title. Please see, "[Should questions include “tags” in their titles?](http://meta.stackexchange.com/questions/19190/)", where the consensus is "no, they should not". – John Saunders Dec 06 '12 at 09:57

3 Answers3

2

The easiest thing you can do is making an agreement that everybody must be always pass DateTime as UTC. This way, you reduce the process time (to serialize timezone) and data size.

Ekk
  • 5,627
  • 19
  • 27
  • 1
    +1, we do the same on our project. BTW, renaming property `public System.DateTime date` to `public System.DateTime dateUTC` could make things more clear. – alex.b Dec 06 '12 at 10:32
  • The problem here is service expects UTC, but from a .net client when i try to pass datetime as UTC , the soap request still appears without Z in end. – Rajee Dec 06 '12 at 10:46
  • @Rajee You don't have to worry about Z at the end. You just convert the time to Utc then send it to the service. You service should process date value (without z) as Utc time. It just like when you talk to your coworkers it's 10 in the morning they all know that you mean 10 at your local time without saying "10 in the morning GMT + 10." – Ekk Dec 06 '12 at 12:31
  • Ah, I get what you are saying, but the problem is i dont have control over web service. – Rajee Dec 06 '12 at 13:48
  • Sometimes the remote service expects to see the serialized XML in a particular way (with the Z) and is possibly a giant bureaucratic organization with no interest in making agreements with me. But *technically* this certainly is the right answer. – msulis Mar 26 '14 at 20:37
1

Ok , Finally solved this.Link Force XmlSerializer to serialize DateTime as 'YYYY-MM-DD hh:mm:ss' was very useful. I added a string attribute similar to the one described in the link above and that seems to have fixed the issue.

/// <remarks/>
[System.Xml.Serialization.XmlIgnore]
public System.DateTime date
{
    get
    {
        return this.dateField;
    }
    set
    {
        this.dateField = value;
    }
}

/// <remarks/>

[System.Xml.Serialization.XmlElementAttribute("date", Order = 0)]
public System.String somedate
{
    get { return this.date.ToString("yyyy'-'MM'-'dd'Z'"); }
    set { this.date = System.DateTime.Parse(value); }

}

However, modifying generated proxy is definitely not the preferred way.

Community
  • 1
  • 1
Rajee
  • 272
  • 2
  • 8
1

From another stackoverflow link dealing with a separate issue, you may want to consider the following code for setting up your datetime struct:

C# DateTime to UTC Time without changing the time

other gets treated as UTC time based on the time specified by datetime and serializes with the "Z" at the end in the web service. I was having the same issue, but rather than try to fix the serialization code, the root issue for me seemed to be the datetime member wasn't being treated as UTC time.

Nick
  • 11
  • 1