Convert.ToString (DateTime), возвращающий британский формат вместо американского - PullRequest
2 голосов
/ 05 августа 2011

У меня проблема с тем, что строка DateTime в C # не удается преобразовать в SQL DateTime, поскольку она таинственным образом форматируется как дата в Великобритании (дд / мм / гггг).Вот серия событий:

  1. Объект создан на удаленном сервере в США и сериализован в XML.
  2. XML десериализуется на локальном компьютере в ЦА обратно вобъект.Дата сериализации выглядит следующим образом: 2011-07-13T09: 56: 57.0542425
  3. Приложение пытается сохранить объект в базе данных, вызывая ранее упомянутую хранимую процедуру.Он (без необходимости) преобразует дату в строку перед передачей ее в качестве параметра в sproc с помощью Convert.ToString (DateTime).
  4. Sproc завершается с ошибкой SqlException «Ошибка преобразования типа данных nvarchar в datetime», посколькустрока, которую он получил для своего типизированного параметра DateTime, была в формате дд / мм / гггг (и язык базы данных - английский США).

Теперь код не должен преобразовывать дату и время в строкутолько для преобразования обратно в datetime в SQL, но эта проблема только начала возникать (на более чем одном компьютере) после того, как все было хорошо в течение года.Поэтому я подумал, что культура БД или ОС, должно быть, недавно изменилась, заставив их использовать разные форматы даты.К моему удивлению, после изменения ОС (Windows 7) с английского (Канада) на английский (США) и перезапуска проблема по-прежнему возникает.Чтобы сделать это еще более запутанным, ошибка не возникает, когда один и тот же тип объекта создается локально, а не десериализовано, независимо от региональных настроек.Единственное отличие заключается в том, что версия сериализации происходит в службе Windows, а локально созданная версия объекта - в приложении Windows.Они оба используют свою собственную копию сборки, которая вызывает Convert.ToString (DateTime), но они используют одну и ту же версию этой сборки.Я в замешательстве.

PS .NET 2.0 и SQL Server 2005

Ответы [ 3 ]

2 голосов
/ 05 августа 2011

Почему вы не форсируете формат DateTime.ToString(), используя ту культуру, которую вы конкретно хотите - или задаете пользовательское правило форматирования, которое соответствует вашим функциям SQL?

Для пользовательского форматирования вы можете посмотреть здесь или для форматирования, специфичного для культуры, вы можете посмотреть здесь

1 голос
/ 05 августа 2011

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

Если это так, то, возможно, эти инструкции от Microsoft могут применяться.

1 голос
/ 05 августа 2011

Я не верю, что в DateTime есть что-то, кроме простого 64-битного целого числа - в основном это дата / время в тиках и "вид", закодированный в верхней паре битов. Таким образом, создание нового DateTime создается локально. Другими словами, я боюсь, что сомневаюсь в ваших утверждениях о том, что происходит, когда «объект такого же типа создается локально».

Вот где я бы начал исследовать - избавиться от вызова базы данных, а просто записать результат вызова Convert.ToString(serializedDateTime) и Convert.ToString(new DateTime(2011, 7, 25)) (как пример даты, когда строковое представление делает очевидным, в какую сторону являются). Я был бы действительно удивлен, если бы вы могли получить это для двух разных форматов даты - один для значения, которое было десериализовано, и один для значения, которое было создано локально.

Какого "вида" DateTime вы получаете после десериализации (т. Е. В результате получения свойства Kind)? С этой информацией вы сможете построить точно равное DateTime значение.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...