0

I am having an issue with a date time that passed back from a third party web service.

The date field (visitDate) that coming from the service is a date type. Following is what's in the WSDL.

<xs:element minOccurs="0" name="visitDate" type="xs:dateTime"/>

After adding reference to the service using .NET, the reference file a property for the visitDate and it's a DateTime type. So, the value returns from the visitDate property is translated to local time zone.

The service is always returning the time part as midnight+2 ("2015-04-14T00:00:00+02:00"), .NET translates the date to the previous date e.g: “2015-04-13 23:00:00”. Due this my report always showing the wrong date (a day behind).

Guys who done the service is saying either visitDate.AddDays(1) or use AfterReceiveReply method of the message inspector that does a string manipulation to strip off the time zone portion and recalculate the date.

I am just wondering if anyone have experienced issue like this and hopefully can shed some light on a solution please?

Update

Just to explain this bit more: The visitdate that returns from the service is a date that is added in a previous transaction via an input screen. When returning the visitdate service always replace the time element with the “00:00:00” hence why you see the date as "2015-04-14T00:00:00+02:00".

Following is what happens (based on today’s date)
Input value: 17/04/2015 11:52:39
Service return: 2015-04-17 T00:00:00+02:00
.Net parse as: 2015-04-16 23:00:00

The date I want to display in my report is “2015/04/17” not “2015/04/16”.

Update We raised this with the third party team and here is what they recommend

If the value in the xml is ‘2015-04-14T00:00:00+2:00’ and the parsed value is ‘2015-04-13 23:00:00’: Something like: visitDate.AddDays(1).Date will give you: 2015-04-14 00:00:00

If WCF is being used, a cleaner (but more complex) solution is to add code to the AfterReceiveReply method of the message inspector that does a string manipulation to strip off the time zone portion.

Chint
  • 23
  • 3
  • What do you mean by _.NET translates the date to the previous date_ exactly? This service return value is `string` or `DateTime`? How you do handle this return value exactly? We need more details about your problem. – Soner Gönül Apr 17 '15 at 10:26
  • Hi, I've updated the question with bit more detail. – Chint Apr 17 '15 at 11:30

2 Answers2

1

The service is returning a UTC date format: http://en.wikipedia.org/wiki/ISO_8601, and is in a time zone 2 hours ahead of UTC (+02:00). You are 1 hour behind UTC, and thus 3 hours behind the service, hence midnight UTC is 02:00 AM for the service, and 11:00 PM (23:00) for you.

So far so good. You need to decide what you want to do with the date. Do you want to display it in your local time, the service's local time, or in UTC? If the first one, then your report is currently correct, as it is showing the previous day compared to the service, because when it is UTC midnight, at the same moment in time the service is already in the next calendar day compared to your time zone.

Polyfun
  • 9,479
  • 4
  • 31
  • 39
0

Your field is a DateTime (xs:dateTime), not a date (xs:date).

Unfortunately, WCF does not support xs:date, which means that there will be ambiguity for date-only parameters when communicating between machines in different time zones.

If you can get your third-party service provider to make a change, possible workarounds would be:

  • Return xs:dateTime without time zone information (2015-04-14T00:00:00), which I think you can do with a .NET service by specifying DateTimeKind.Unspecified.

  • Return a date in UTC.

You may also be able to use DateTimeOffset in your client code to get a date/time in the server's timezone, then interpret it as appropriate.

Community
  • 1
  • 1
Joe
  • 122,218
  • 32
  • 205
  • 338