Принудительный часовой пояс для приложения

Question

Трудная ситуация здесь. Наше приложение работает в системе, которая задана с определенным TimeZone (скажем, по времени в Азии). Однако клиент запрашивает, чтобы его приложение выполнялось с использованием часовой пояс в Европе.

Поскольку наши данные не хранятся в UTC, есть ли в любом случае, мы можем установить языковой стандарт в приложении, чтобы все отображаемые даты использовали TimeZone в Европе? Я понимаю, что мы можем установить информацию о культуре в Web.Config, но я не уверен, что это может помочь установить TimeZone.

BTW наше приложение работает с использованием C# WebForm и MSSQL 2008 R2.

Answer 1

Как ваши данные хранится полностью отличается от того, как вы выбираете дисплей. Предполагая, что даты и время предназначены для представления фиксированных точек во времени (вместо плавающих «локальных» времен), я попытался бы написать как можно больше приложений с DateTime значениями в UTC. Когда вы извлекаете данные, конвертируйте их из своего «часового пояса», если вам нужно (вы не сказали , где зона, в которой хранятся ваши данные) и конвертировать ее при ее сохранении. Когда вы покажите, отобразите его в зависимости от того, какой часовой пояс вам нужен.

Вам не нужно устанавливать это на глобальном уровне, насколько это касается .NET. У вас может быть параметр конфигурации приложения (если вы действительно этого хотите) и «вспомогательный» код для его конвертирования всякий раз, когда вы необходимо отобразить. Я бы сделал это очень четко: вы действительно не хотите, чтобы конверсии происходили неявно, когда дело доходило до времени.

(Я бы также упомянул, что моя библиотека Noda Time может пригодиться в качестве более четкого API, когда дело доходит до дат и времени. Разумеется, я предубежден. Я также предлагаю перейти на сохранение всего в UTC, если . вы можете ... и только там, где это уместно, конечно)

Answer 2

вы должны хранить даты с DateTimeOffset:

Представляет точку во времени, как правило, выражается в виде даты и времени день, относительная к скоординированному универсальному времени (UTC).

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

Как пояснил Джон Скит в комментарии в моем ответе, необходимо сохранить идентификатор часового пояса вместе с DateTimeOffset, чтобы получить полную дату + информацию о времени и сделать ее полностью конвертируемой.

В другой стороны, вы не можете хранить данные в часовом поясе, но с DateTimeOffset, как это со всем времени идентификатора зоны, а затем вы будете конвертировать его в требуемой временной зоне в зависимости в пользовательском профиле или в области часового пояса и/или в настройках культуры в прикладном уровне.

Наконец, вы можете преобразовать такие DateTimeOffset используя this TimeZoneInfo.ConvertTime(DateTimeOffset, TimeZoneInfo) overload.

Answer 3

Как об изменении локали?

CultureInfo currentCulture = Thread.CurrentThread.CurrentCulture; 
if (currentCulture.Name != "sv-SE") 
{ 
    // Change the current culture to sv-SE and serialize the date. 
    Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture("sv-SE"); 
} 

// Do something with a date in swedish timeZone 
var swedishNow = DateTime.Now; 

// Restore back to the original culture, when finished 
Thread.CurrentThread.CurrentCulture = currentCulture;