Обработка даты и времени в приложениях, обслуживающих клиентов в нескольких часовых поясах?

Question

Проблемы интернационализации, связанные с обработкой строк, в значительной степени можно решить, следуя советам:используйте Unicode и храните все в базе данных в формате UTF-8, тогда вы сможете обслуживать клиентов, используя все языки мира.

Но как насчет проблем интернационализации, связанных с обработкой даты и времени?

Вопросы:

• Существуют ли аналогичные, простые в использовании передовые методы решения проблем интернационализации, связанных с обработкой времени?
• Как убедиться, что ваши приложения могут обслуживать клиентов, работающих в разных часовых поясах?С какими проблемами вы столкнулись и как вы их решили?

Answer 1

У меня есть следующие советы,

1. Храните все свое время в базе данных с одним часовым поясом, предпочтительно Zulu (GMT).
2. Назначьте часовой пояс каждому пользователю при регистрации.Обычно мы определяем это по языку страницы регистрации или коду, встроенному в рекламную ссылку.Иногда нам приходится спрашивать пользователя.
3. Сделайте так, чтобы клиенты учитывали часовой пояс.Это означает, что клиент не может отображать время с сервера как есть.Должно отображаться в местном часовом поясе и в местном формате.
4. Клиенту следует приложить некоторые усилия, чтобы получить информацию о часовом поясе системы.Если нет, сервер может сделать предположение на основе различных данных.Мы получили хорошие результаты, используя сначала язык, а затем IP-адрес.В любом случае клиенту необходимо отображать время с информацией о зоне, чтобы пользователь знал, что происходит, когда время неправильное.
5. Нужны специальные флаги для определенных значений времени, на которые не влияет часовой пояс.У нас была ошибка: день рождения пользователя меняется при смене языкового стандарта.Другие вещи, относящиеся к этой категории, включая праздники, часы работы магазинов и т. д.
6. Если вам необходимо синхронизировать часы с сервером, не меняйте системное время, просто сохраните разницу в своем клиенте.У нас было требование безопасности: часы должны быть синхронизированы с хостом.Таким образом, наш клиент синхронизирует системные часы с нашим сервером при запуске.Это неправильно.Для более старых систем, таких как Windows 95, без часового пояса, мы изменили время на GMT.Наконец, старые клиенты ушли, но мы столкнулись с новой проблемой: мы испортили точное время от NTP.

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

Answer 2

У ZZCoder есть несколько положительных сторон.Вот еще несколько:

• Все значения даты и времени должны иметь связанный часовой пояс.Вы должны определить, что это означает, если у даты и времени ее нет (например, в некоторых случаях это будет означать GMT+0;в других случаях это происходит потому, что код находится в процессе его определения и назначения).
• Вероятно, вам потребуется прикрепить события с датой и временем к местоположению.Это означает, что у вас будет способ выяснить, когда разрешено изменение часового пояса даты и времени.Это решает проблему переноса дней рождения, но также позволяет разумно вести себя, когда начинается или заканчивается летнее время.Однако будьте осторожны с непреднамеренными связями:при настройке встречи для нескольких человек в разных часовых поясах следует ссылаться на одну каноническую запись, а не копировать дату и время и локализовать их.
• Не расчеты сделайте сами:всегда всегда всегда попросите библиотечные функции выполнить вычисления даты и времени.

Answer 3

Мне повезло: я использовал JavaScript, чтобы клиент сообщал нам свой часовой пояс.Насколько я помню, это включало вычисление текущего времени на компьютере пользователя по местному времени, а затем сравнение его с временем Zulu.