.NET Использование локальных часовых поясов

Question

У меня возникла проблема с датой, прошедшей с веб-службы третьей стороны.

Поле даты (visitDate), исходящее из службы, относится к типу даты. Ниже приводится то, что находится в WSDL.

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

После добавления ссылки на службу с использованием .NET, ссылка на файл свойство для visitDate и это тип DateTime. Таким образом, значение, возвращаемое из свойства visitDate, переводится в локальный часовой пояс.

Служба всегда возвращает часть времени как полночь + 2 («2015-04-14T00: 00: 00 + 02: 00»), .NET переводит дату на предыдущую дату, например: «2015-04- 13 23:00:00 ". Из-за этого в моем отчете всегда отображается неправильная дата (день за днем).

Ребята, которые выполнили эту услугу, говорят либо visitDate.AddDays (1), либо используют метод AfterReceiveReply инспектора сообщений, который выполняет строковое манипулирование, чтобы отменить часть часового пояса и пересчитать дату.

Мне просто интересно, есть ли у кого-нибудь подобная проблема, и, надеюсь, может пролить свет на решение, пожалуйста?

---

Update

Просто, чтобы объяснить это немного больше: visitdate, что возвращается из сервиса является дата, которая добавляется в предыдущей транзакции через экран ввода. При возврате сервиса visitdate всегда заменяйте элемент времени «00:00:00», поэтому вы видите дату «2015-04-14T00: 00: 00 + 02: 00».

Ниже то, что происходит (на основе текущей даты)
Входное значение: 17/04/2015 11:52:39
возвращение Услуги: 2015-04-17 T00: 00: 00 + 02: 00
.Net parse as: 2015-04-16 23:00:00

Дата, которую я хочу показать в своем отчете, - «2015/04/17», а не «2015/04/16».

Update Мы подняли это с командой третьей стороной, и вот что они рекомендуют

Если значение в XML является «2015-04-14T00: 00: 00 + 2: 00» и разобранное значение '2015-04-13 23:00:00': Что-то вроде: visitDate.AddDays (1) .Date даст вам: 2015-04-14 00:00:00

Если WCF является (более сложное) решение состоит в том, чтобы добавить код к методу AfterReceiveReply инспектору сообщений, который выполняет строковое манипулирование, чтобы отключить часть часового пояса.

Answer 1

Служба возвращает формат даты UTC: http://en.wikipedia.org/wiki/ISO_8601 и находится в часовом поясе на 2 часа вперед от UTC (+02: 00). Вы на 1 час меньше, чем UTC, и, следовательно, на 3 часа позади обслуживания, поэтому в полночь UTC - 02:00 для обслуживания и 23:00 (23:00) для вас.

Пока все хорошо. Вам нужно решить, что вы хотите делать с датой. Вы хотите отобразить его в свое местное время, по местному времени службы или в UTC?Если первый, то ваш отчет в настоящее время верен, так как он показывает предыдущий день по сравнению с сервисом, потому что, когда он является полночь в полдень, в тот же момент времени служба уже в следующий календарный день по сравнению с вашим временем зона.

Answer 2

Ваше поле DateTime (xs: dateTime), а не дата (xs: date).

К сожалению, WCF does not support xs:date, что означает, что при передаче данных между машинами в разных часовых поясах будет неопределенность для параметров только для даты.

Если вы можете получить у поставщика услуг третьих сторон, чтобы сделать изменения, возможные обходные бы:

• Возврат хз: DATETIME без информации о зоне времени (2015-04-14T00: 00: 00) , который, я думаю, вы можете сделать с помощью службы .NET, указав DateTimeKind.Unspecified.

• Верните дату в UTC.

Вы также можете быть в состоянии использовать DateTimeOffset в коде клиента, чтобы получить дату/время в часовом поясе сервера, а затем интерпретировать его по мере необходимости.