Parsing Date Time Строка возвращается Неправильно

Question

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

Пользователь отправит XML-файл в веб-службу, и он де-сериализует XML в Object, а затем сериализует его в формате XML, требуемом клиентом.

Я столкнулся с нечетной ситуацией, где в XML-файле, отправляемом в веб-службу, есть два разных формата DateTime, в этом случае DateTimes в XML-файле, который был выведен, неверны. Однако, если я передаю два DateTimes в двух отдельных файлах, они правильно обрабатываются.

Вот два DateTimes:

Date = "2015-09-23T14: 30: 00 + 01: 00"

Date = "2015-09-23T14: 30: 00"

при проанализирован в файле с одной или другой стороны они оба разобрать, как 14:30, который является правильным, однако, когда оба формата в файле второго DateTime разбирает в 15:30 и первым 14:30.

Я попытался назначить CultureInfo, установив по местному времени.

Я использую XmlSerializer Class и XmlSerializer.Deserialize Method, чтобы прочитать XML-файл, отправленный веб-службе на объект, который я создал.

У меня тогда есть простой картограф, который записывает значения в XML и изменяет несколько имен атрибутов и узлов. Код для записи DateTime в строку является:

xmlWriter.WriteAttributeString("startdatetime", dateTime.ToString("s")) 

Что действительно бросает меня в том, что все это работает, когда они находятся в отдельных файлах, но не тогда, когда он находится в файле с двумя отдельными форматами DateTime.

Answer 1

Есть несколько вещей, которые работают против вас:

1. Ваш вклад разнообразен.

   • "2015-09-23T14:30:00+01:00" явно определенный момент времени, описываемого даты, времени, и смещение от UTC.

   • "2015-09-23T14:30:00" не обеспечивает смещение, поэтому он не напрямую карта на определенный момент времени.

2. "2015-09-23T14:30:00+01:00" Когда десериализуется к DateTime по XmlSerializer, смещение применяется, чтобы добраться до UTC, а затем он преобразуется в по местному времени зоны сервера, на котором он работает. Результат: DateTimeKind.Local.

   • В облаке, зона местного времени уже UTC, поэтому он вычитает час и остается там, хотя она до сих пор DateTimeKind.Local, не DateTimeKind.Utc.

   • Также обратите внимание, что вы указали 15:30, но 14:30+01:00 is 13:30 UTC. Кроме того, я не вижу разницы в поведении, когда только один или другой файл находится в одном файле. Если вы можете, отредактируйте свой вопрос, чтобы показать код, который воспроизводит его таким образом.

3. Когда "2015-09-23T14:30:00" десериализируется к DateTime по XmlSerializer, он будет иметь DateTimeKind.Unspecified. Если вы намерены использовать это для обозначения UTC, это предположение, которое вы применяете после этого факта. Это может быть также местное время в каком-то другом часовом поясе. Для явно UTC исходная строка должна быть либо "2015-09-23T14:30:00Z", либо "2015-09-23T14:30:00+00:00".

4. Когда "2015-09-23T14:30:00+01:00" десеризуется до DateTimeOffset от XmlSerializer, он задыхается. Класс XmlSerializer по-прежнему не понимает стандартного формата ISO DateTimeOffset. Есть some workarounds here, но на самом деле это должно быть исправлено в рамках (IMHO).

А что делать? Ну, самое легкое занятие (и то, что делают большинство людей) - удалить свойства DateTime из этих классов и вместо этого использовать string. Таким образом вы получаете точное значение, указанное в данных. Затем вы можете взять его через DateTime.Parse или DateTimeOffset.Parse самостоятельно, со всеми различными опциями, которые предоставляют эти методы. Вот пример этого с помощью подхода «Приятельские свойства» in this answer here.

После того, как вы преобразовали как строковые значения DateTimeOffset, вы можете использовать либо .DateTime свойство для получения даты и времени необработанного оригинала при условии, или использовать .UtcDateTime собственности, или любой из других свойств.

Помните, что если вы проанализируете строку ISO без смещения как DateTimeOffset, вы будете поданы для вас. По умолчанию он будет использовать местный часовой пояс компьютера, на котором он запущен. Если ваш код находится в Azure, это будет UTC или +00: 00 - так что все должно быть в порядке.