2011-10-24 4 views
7

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

Везде Культура Формата данных different- мы используем формат mm/dd/yyyy где каждый, но упаковывают некоторые сервера имеет значение культуры dd/mm/yyyy, тогда наш сайт генерирует исключение Datetime.

+4

для человека, который голосовал, чтобы закрыть, потому что «это трудно сказать, что спрашивается здесь»: что-то путаю? –

ответ

11

Вы должны указать, какую культуру вы хотите использовать при преобразовании строки в дату.

Культура, которую вы должны использовать, зависит от того, какая культура датируется форматированием.Например, если все даты вы разборе отформатированы как словацкий:

String s = "24. 10. 2011"; 

Затем вам нужно разобрать строку, как если бы это было в Словакии (Словакия) (sk-SK) культура:

//Bad: 
d = DateTime.Parse(s); 

//Good: 
d = DateTime.Parse(s, CultureInfo.CreateSpecificCulture("sk-SK")); //Slovak (Slovakia) 

Если ваши даты находятся в таджикском (Таджикистан кириллицы), то вам нужно разобрать его как tg-Cryl-Tj:

String s = "24.10.11" 

DateTime d = DateTime.Parse(s, CultureInfo.CreateSpecificCulture("tg-Cryl-Tj")); 

Это приводит к вопросу: какой формат даты вы используете? Вы не должны полагаться на настройку локали сервера, вы должны решить, какой формат вы хотите.

//Bad 
String s = d.ToString(); 

//Good 
String s = d.ToString(CultureInfo.CreateSpecificCulture("si-LK")); //Sinhala (Sri Lanka) 

//s = "2011-10-24 12:00:00 පෙ.ව." 

Я подозреваю, что вы предпочитаете делать все на английском языке. Но тогда вы должны решить, какой вариант английского языка:

  • en-AU (английский Austrailia): 24/10/2011
  • en-IA (Английская Индия): 24-10-2011
  • en-ZA (Английская Южная Африка): 2011/10/24
  • en-US (Английский США): 10/24/2011

Я подозреваю вас предпочитают English (India) (en-IA).


Но если вы действительно не можете решить, какие культуры использовать при преобразовании даты в строки и наоборот, а также даты никогда не должно быть показано пользователю, то вы можете использовать Инвариантные культуры:

String s = "10/24/2011" //invariant culture formatted date 

d = DateTime.Parse(s, CultureInfo.InvariantCulture); //parse invariant culture date 

s = d.ToString(CultureInfo.InvariantCulture); //convert to invariant culture string 
+0

благодарит за прекрасное объяснение – Murtaza

+1

Вы никогда не должны использовать какие-либо настройки культуры из домена или os. Если кто-либо переопределяет их по какой-либо причине (например, другое приложение работает неправильно), ваше приложение перестает работать. Если формат всегда один и тот же, вы должны использовать tryparseexact или parseexact. – Peter

+0

Для всего этого на окнах 10 по умолчанию используется формат даты по умолчанию без пробелов. – Fanda

0

Никогда не зависит от локали сервера по умолчанию. В вашем случае, это означает:

  • использовать подготовленные заявления, где вы передаете дату в качестве объекта (неформатированный) дату, а не как (отформатированный) строкового объекта. Вы никогда не должны использовать строки для представления дат в своем приложении в любом случае, так как вы не можете выполнять на них определенные по дате функции (например, добавление 1 месяца, получение последнего дня текущей недели и т. Д.)

  • Используйте SQL-функции, такие как to_date и to_char везде (точные названия зависят от вашей СУБД), если вы действительно нужно использовать строковые объекты в приложении

+0

Простое и понятное решение спасибо, но Ян Бойд объяснил, почему мы должны работать над этим анализом. Спасибо вам обоим. – Murtaza

1

никогда, никогда, хранения дат внутренне как строки. Не в базе данных, а не в вашем приложении.

Если вам нужно переместить значения даты между серверами, перейдите в двоичный файл. Или, если вам действительно нужно использовать строки, используйте ToString(CultureInfo.InvariantCulture) - или просто сериализуйте свойство Ticks.

Кроме того, никогда не передавать даты в виде строк в базу данных с помощью SQL-команд, которые вы создаете с использованием кода. Используйте для этого SqlParameter, или даже лучше, полагаться на некоторый O/R Mapper, такой как Entity Framework или Linq to SQL.

0

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

Скорее всего, вы захотите найти свой код для DateTime.Parse или аналогичного. У нас есть набор методов расширения на DateTime, которые мы используем вместо этого, чтобы заставить правильную культуру.