Часовой пояс по умолчанию на пользователя, установленный в бизнес-логике - PullRequest
Новая
       24

Часовой пояс по умолчанию на пользователя, установленный в бизнес-логике

0 голосов
/ 14 июля 2011

У меня есть приложение, в котором все значения DateTime всегда соответствуют времени сервера.Это означает один часовой пояс.Идея состоит в том, чтобы сделать приложение совместимым во всем мире.Первым шагом является преобразование всех сохраненных DateTime в базе данных в UTC, это не проблема.Второй шаг - предположить наличие часового пояса для пользователя (исходя из бизнес-логики) и использовать его по умолчанию для отображения и анализа ввода пользователя.Кроме того, было бы неплохо, если бы такие методы, как DateTime.Now и другие вызовы методов, которые создают даты и время без явной информации о часовом поясе / регионе, также предполагали бы этот часовой пояс / регион.

Идея состоит в том, чтобы предположить часовой пояс дляПользователь из базы данных.У меня есть пользователь и его часовой пояс, это не проблема.
Проблема в логике представления.Во всем коде есть методы DateTime.now, для преобразования всех этих методов очень много работы.
Чтобы избежать этого, мне нужна глобальная настройка часового пояса, когда DateTime знает, какой это часовой пояс.Желательно на родовом месте. 

class business logic 

InitializeCulture() 
 set time zone for user 
end function 

end class

class presentation logic  

sample()
 TimeOfTheCurrentUser = DateTime.now  
end function

end class

1 Ответ

1 голос
/ 15 июля 2011

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

  1. Хранить всю информацию о дате и времени вУНИВЕРСАЛЬНОЕ ГЛОБАЛЬНОЕ ВРЕМЯ.Хранение его как локальное время (на сервере или где-либо еще) всегда несет в себе риск того, что кто-нибудь где-нибудь когда-нибудь забудет конвертировать их, и результаты будут не идеальными.Конечно, это означает, что даты и время должны создаваться с помощью DateTime.UtcNow или с правильным выбранным DateTimeKind (это относится и к синтаксическому анализу).

  2. Очевидно, что вам нужно преобразовать часовой пояс перед отображениемDateTime для конечного пользователя.И вы наверняка понимаете, что вам нужно получить эту информацию из какого-то источника (отсюда и вопрос).Это может быть где-то на стороне клиента (что особенно хорошо работает с толстым клиентом и не очень хорошо с JavaScript тонкого клиента), но также может быть и профиль пользователя.Если ваше приложение имеет профили пользователей, я бы определенно рекомендовал разрешить пользователю выбирать предпочтительный часовой пояс.Другие настройки, связанные с g11n, предпочтительнее для электронной почты или предпочитаемого языка.Все эти настройки должны быть обнаружены и предварительно выбраны (чтобы пользователю не приходилось думать или, что еще важнее, нажимать слишком много).

  3. Для преобразования DateTime классов в местное время в другое времязона, вы бы использовали TimeZoneInfo класс.Есть несколько способов сделать это ...

Если вы реализуете этот метод, вы можете столкнуться с проблемой с именами часовых поясов - они в культуре сервера, поэтому вам нужно будетexternalize (переместить в файл ресурсов) то, что DisplayName TimeZoneInfo показывает вам, и пусть переводчики выполняют свою работу.

Также просто короткое слово, которое я имел в виду, определяя часовой пояс.
На толстом клиенте вы бы это сделалипросто читая местный часовой пояс: 

TimeZoneInfo currentTimeZone = TimeZoneInfo.Local;

С JavaScript (тонкий клиент) это не так просто.Единственное, что вы можете получить, это смещение часового пояса (которое может варьироваться в зависимости от даты и времени) на данную дату: 

var date = new Date();
var offset = date.getTimezoneOffset(); // GMT offset in minutes
...