Переопределить сериализацию DateTime для параметров ASP.NET WebMethod

Question

Я работаю над устранением ошибки в большой базе кода, когда никто не обращал внимания на местное время по сравнению с временем UTC.

Нам нужен способ глобального игнорирования информации о часовом поясе объектов DateTime, отправляемых в наши веб-службы ASP.NET и из них. У меня есть решение для операций извлечения. Данные возвращаются только в наборах данных, и я могу искать столбцы DateTime и устанавливать для DateTimeMode значение Unspecified. Это решает мою проблему для всех данных, передаваемых туда и обратно внутри набора данных.

Однако объекты DateTime также часто передаются непосредственно в качестве параметров в веб-методы. Я хотел бы удалить любую информацию о часовом поясе. Вместо того, чтобы искать в нашем клиентском коде и использовать DateTime.SpecifyKind (..), чтобы установить для всех переменных DateTime значение Undefined, я бы хотел сделать какое-то глобальное переопределение ASP.NET для мониторинга входящих параметров и удаления информации о часовом поясе.

Возможна ли такая вещь? Или есть другой способ сделать то, что я хочу?

Просто повторюсь - мне все равно, какие часовые пояса, все находятся в одном часовом поясе. Но у нескольких пользователей плохо настроены машины, неправильные часовые пояса и т. Д. Поэтому, когда они отправляют 1 июля 2008 г., я получаю 30 июня 2008 г. 22:00:00 на стороне сервера, где он автоматически преобразует их из своих местное время по местному времени сервера.

Обновление: Еще одна возможность была бы, если бы можно было внести изменения в коде .NET на стороне клиента, чтобы изменить способ сериализации объектов DateTime с Kind 'Undefined'.

Answer 1

Я часто сталкивался с этим во многих приложениях, сервисах и на разных платформах (.NET, Java и т. Д.). Пожалуйста, поверьте мне, что вы НЕ хотите долгосрочных последствий притворяться, что вас не волнует часовой пояс. После погони за множеством ошибок, которые чрезвычайно сложно и дорого исправить, вам захочется, чтобы вы позаботились.

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

Общепринятая отраслевая конвенция заключается в том, чтобы принудить все к UTC и установить все производственные аппаратные часы на UTC (что означает серверы, сетевые устройства, например маршрутизаторы и т. Д.). Затем вы должны перевести на / из местного часового пояса пользователя в пользовательском интерфейсе.

Если вы исправите это правильно сейчас, это может быть легко и дешево. Если вы намеренно сломаете его, потому что считаете, что это будет дешевле, у вас не будет никаких оправданий, когда вам придется распутывать ужасный беспорядок.

Обратите внимание, что это похоже на общую проблему со строками: не существует такого понятия, как простой текст (строка, лишенная кодировки символов), и не существует такой вещи, как обычное (без часового пояса) время / дата. Притворство в противном случае является источником сильной боли и страданий, а также смущающих ошибок.

Answer 2

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

<XmlElement(DataType:="date")> 

Это изменяет сгенерированный wsdl, чтобы иметь тип s: date вместо s: dateTime. (Обратите внимание, что простое наличие типа параметра метода .NET как Date, а не DateTime НЕ ПОЛУЧИЛО этого). Таким образом, клиент теперь отправляет только часть даты DateTime, без информации о времени и информации о часовом поясе.

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

Answer 3

У меня тоже были проблемы с информацией о часовом поясе. Проблема в том, что я уже предоставляю поля даты и времени в UTC. Затем происходит сериализация, и локальное смещение становится частью даты / времени. Даты / время для нашего поставщика в другом часовом поясе были довольно запутаны. Я справился с этой проблемой, используя функцию преобразования tsql в полях datetime в операторе select, который использовал для заполнения своих наборов данных. Это преобразовало поля в строковую переменную, которая автоматически преобразуется в значение datetime на стороне клиента. Если вы просто хотите передать дату, вы можете использовать код 101, чтобы указать только дату. Я использовал 126, чтобы точно указать дату и время в столбцах моей базы данных, при этом информация о часовом поясе удалена.