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

Question

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

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

Вопросы:

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

Answer 1

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

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

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

Answer 2

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

Answer 3

У ZZCoder есть несколько хороших точек. Вот еще:

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