#date #localization #time #utc
#Дата #локализация #время #utc
Вопрос:
В настоящее время я добавляю на веб-сайт систему, похожую на out of office, где пользователи смогут отмечать даты и время своего отсутствия в офисе, чтобы они могли предоставлять информацию других пользователей для использования в качестве резервной копии во время своего отсутствия.
Проблема, с которой я сталкиваюсь, заключается в преобразовании местного времени пользователей в UTC. Я видел другие сообщения, которые решают эту проблему, предоставляя пользователю UTC и заставляя клиента (js) преобразовывать время в местное время и обратно. Однако у меня есть доступ к системе соответствия, которую я могу использовать для преобразования даты на стороне сервера на основе предпочтений часового пояса пользователя.
Мой вопрос заключается в следующем: я должен использовать на стороне сервера преобразования, которые позволят пользователя домашнего местное время планируется поставить (говорят, их нам время, независимо от того, где они вошли в систему), или я должен использовать на стороне клиента конверсия?
Есть ли у кого-нибудь опыт работы с этим? Каковы некоторые из менее очевидных преимуществ / недостатков каждого метода?
Комментарии:
1. Если вам нужны примеры кода, пожалуйста, перечислите технологию. Если это не PHP, я мог бы это предоставить.
Ответ №1:
Хранить все в формате UTC — очень хорошая идея, и я рекомендую вам придерживаться ее.
Существует несколько подходов, которые вы можете использовать. Я предполагаю, что у вас будут профили пользователей. Вы можете предоставить пользователям возможность выбирать часовой пояс, который они предпочитают, и отображать все, используя эту информацию. А также обработка всего пользовательского ввода соответствующим образом (преобразование на стороне сервера, при условии, что часовой пояс является предпочтительным).
Другой способ справиться с этим — фактически использовать смещение часового пояса пользователя через Date.getTimeZoneOffset() и каким-либо образом отправить его на ваш сервер (т. Е. через скрытое поле формы или Ajax). Когда вы знаете это, показать все во времени пользователя было бы проще простого. В этом случае вы можете захотеть преобразовать дату / время на клиенте и отправить его как UTC (или использовать скрытое поле формы со смещением часового пояса).
В обоих случаях вы обрабатываете преобразование даты базы данных на стороне сервера. По моему опыту, это лучший подход. Я хотел бы отметить, что помимо простого преобразования часовых поясов, вам, вероятно, следует подумать о отображении даты / времени в правильном формате (т. Е. в зависимости от значения заголовка AcceptLanguage).
Комментарии:
1. Я хотел бы отметить, что это также опция, позволяющая пользователю указывать свой часовой пояс, но по умолчанию используется часовой пояс текущего браузера для начала. Таким образом, если пользователи не укажут часовой пояс, они все равно будут видеть правильное время. Тем не менее, это все еще оставляет гибкость доступной. Однако, для начала, я полагаю, я просто буду использовать смещение времени текущего браузера, как вы указали. 🙂 Спасибо!
Ответ №2:
Проблема сводится к тому, считаете ли вы, что пользователи будут устанавливать правильное время в своем профиле и считаете ли вы, что у них есть клиент, настроенный на часовой пояс, на который настроен их компьютер.
Если настройка домашнего времени в профиле необязательна (такая, которую большое количество пользователей не установит должным образом), то вам следует использовать время на стороне клиента.
Если вы ожидаете, что многие пользователи будут получать доступ к системе с компьютера, не настроенного на их предпочтительный часовой пояс (скажем, если они получают доступ к ней с компьютера отеля), то вам следует выполнить преобразование времени на сервере.
Если к вам применимы оба этих параметра, будь ты проклят, если ты это сделаешь, и будь ты проклят, если не сделаешь.
Если ни одно из них не применяется, то оба решения обеспечат равные, удовлетворительные результаты.
Независимо от того, что вы выберете, хорошей идеей будет добавить временную метку ко времени, когда вы его отображаете, чтобы устранить любую путаницу.