DataSet.Locale, что он делает?
Может кто-нибудь, пожалуйста, скажет мне, что такое использование DataSet.Locale и можно ли его использовать для решения этой проблемы.
Мой сервер находится в США, и я выполняю запрос к нему. Данные, содержащиеся в таблице как на удаленном сервере (США), так и на локальном, одинаковы.
Проблема заключается в том, что я получаю DataSet с помощью WebService с удаленного сервера. В столбце «Даты» отображается предыдущая дата. Например, в столбце даты указано «14 января 2007 г.», но при извлечении отображается «13 января 2007 г.».
Я не могу определить причину, так как все остальное работает нормально.
Ответы 3
Свойство используется для определения локали, которую набор данных будет использовать при сравнении строк в нем.
Для получения дополнительной информации см. Справочную страницу MSDN здесь.
Обновлено: Просто в отношении вашей проблемы: где находится «локальная» машина? Не случайно ли вы пересекаете дату на сервере?
Не всегда днем, но это происходит особенно утром, как вы упомянули.
Я думаю, что наиболее вероятным объяснением является то, что в определенные часы дня (утром для индийского часового пояса) сервер в США еще не перешел на ту же дату. Я бы посоветовал проверять это через регулярные промежутки времени в течение дня и определять, есть ли определенное время «отключения».
Похоже на известную проблему с часовым поясом: изменение DataSet.Locale не поможет.
Look at the following KB article for more info: http://support.microsoft.com/kb/842545.
Также посмотрите на свойство DataColumn.DateTimeMode, которое управляет форматом сериализации столбца DateTime. Установка его в DataSetDateTime.Unspecified гарантирует, что смещение не будет добавлено при сериализации.
Я видел это KB. Дело в том, что продукт довольно старый, построен на 2003 версии 1.1. У нас нет доступа к коду веб-службы. Жаль, что возвращенный набор данных содержит измененные даты. Использование DataSet.GetXML дает значение смещения, которое показывает TimeZOne клиентов.
Вероятно, проблема возникает, если временная часть типа DateTime равна 12:00:00. Если это значение (14 января 2007 г., 12:00) будет отправлено в EST, оно будет смещено при перемещении по западным часовым поясам (т.е. 13 января 2007 г., 23:00 по центральному поясному времени).
Лучший способ обойти это - убедиться, что вы храните данные DateTime в инвариантном типе (конвертируете их в UTC pr GMT). Затем, когда вы доберетесь до любого потребителя, которому нужны данные, он сможет преобразовать данные в представление, зависящее от локали. Если вы не можете контролировать, как данные сохраняются, просто убедитесь, что вы преобразовали их в инвариантный тип при извлечении, прежде чем возвращать их клиенту.
Ссылка @Joe, на которую ссылается, полезна, в противном случае вот довольно большой технический документ с подробным описанием передовых методов решения проблемы.
http://msdn.microsoft.com/en-us/library/ms973825.aspx
Вот также переполнение стека Q'n'A относительно некоторых новых технологий.
Лучшие практики сериализации DateTime в .NET 3.5
Примечание: в этой первой ссылке, которую я добавил, есть интересный момент о сериализации некоторых из этих типов дат, в зависимости от того, находитесь ли вы все еще в стеках 1.1 / 2.0. Обратите внимание, он меня пару раз укусил ;-)
Хорошо, если вы первым делом запрашиваете запрос утром в Индии, сервер на западном побережье в США еще не ушел за полночь. Воспроизводится ли проблема в любое время дня?