Отображение времени и информации о часовом поясе пользователю (что, не, как)

Попробуйте графический отдел новостей старого стиля, где у Вас есть часы, маркировал "New York", "London", "Tokyo" и затем "Папуа, Новая Гвинея" или везде, где Ваше конкретное средство просмотра расположено. Можно сделать аналог часов или цифровой или оба.

Никто не будет смущен этим, тогда как я не думаю, что большинство людей действительно знает то, что означает GMT+7 (или безотносительно).

Стратегия должна состоять в том, что времена в UI - при показе или вводе пользователем - находятся в собственном часовом поясе пользователя.

В приложении, с другой стороны, т.е. в коде Ruby и в базе данных, времена всегда сохраняются в часовом поясе UTC.

Ваше задание затем становится, чтобы позволить пользователю выбирать часовой пояс и затем преобразовывать назад и вперед между этим часовым поясом и часовым поясом UTC по мере необходимости.

Эта статья иллюстрирует, как сделать так в среде направляющих.

Это подразумевает, чтобы смочь получить пользовательский часовой пояс или сохранить тот часовой пояс в 'пользовательской' таблице.

Вы упоминаете пакеты. Конвенция в логистике состоит в том, чтобы всегда отображать местное время, который является тем, что UPS и т.п. показывают в истории состояния в их данных дорожки-и-трассировки.

Если бы это, localtime не является часовым поясом текущих пользователей, то я рассмотрел бы аннотирование времени с часовым поясом, например, 9:00 (Европой/Амстердамом).

Обратите внимание, что названия места лучше, чем сокращения, которые могут быть неоднозначными. Вам решать, чтобы решить, более ли полезно сказать пользователю, где время, или каково различие от их часового пояса.

Один путь к избежать проблемы состоит в том, чтобы просто использовать относительные времена, например, 4 часа назад.

Отобразите его с Часовым поясом abreviation

Вместо

15:18 GMT+1

Покажите его Центрально-европейским временем

15:18 CET 

Люди Больше привыкли к наблюдению их собственного часового пояса

Как другие упомянули, я думаю что, если приложение конкретно или локально, то можно опустить часовой пояс или сделать другие предположения.

Если это глобально, то Вы хотите хранить данные последовательно (всегда UTC), то преобразуйте для дисплея. Кроме того, Вы хотели бы позволить пользователю указать его часовой пояс и возможно также форматирование даты и времени; или путем предоставления нескольких статических опций или предоставления им полной мощности указать строку формата, если они совершенствуются достаточно, чтобы сделать так.

Если Вы не хотите давать опции своим пользователям, то простой HH:MM TZ или GMT HH:MM +/-H кажутся соответствующими? Или Вы могли даже просто отобразить время, локальное для сервера, затем в сноске или FAQ, сказать, что "всеми случаями является PST" или независимо от того, что это.

Как пользователь, я предпочел бы максимальную конфигурируемость, но я предполагаю, что смещаюсь, будучи программистом.

Я думаю, что этому нельзя ответить окончательно отсутствующее конкретное приложение. Например, в приложении интранет для всех пользователей в том же часовом поясе, можно часто опускать часовой пояс полностью. Для приложения фондового рынка можно хотеть сделать время относительно часового пояса рынка. Для приложения социальной сети можно хотеть сделать время относительно часового пояса пользователя. Я думаю общие принципы, которые применялись бы:

1. Если существует возможность беспорядка, необходимо всегда указывать часовой пояс
2. Необходимо работать с пользователями, чтобы узнать, как они хотят, чтобы время было отображено.

Мне нравится GMT+offset (предполагающий, что смещение "обычно" будет часовым поясом пользователя). Как дополнительная подсказка, предоставьте подсказку, перечисляющую некоторые города в том часовом поясе (один на полушарие), или гиперссылка к некоторой странице, объяснив часовой пояс более подробно.

Это - ужасно контекстно-зависимая ситуация. Я хотел бы основываться на предложениях postos и tvanfosson. Я не думаю, названия городов и стран необходимы кроме помочь людям установить свое местное время и возможно в диалоговом окне для установки времен, которые могли бы быть для других местоположений, когда они только знают желаемое местное время (сложная задача для не сокрушения/отвлечения пользователей с тем, что является помехой им).

Если местоположение связано со временем, то дата и время в том местоположении является часто соответствующей (например, при разговоре о закрытиях рынка, событиях, прибытии прохождения и отъездах, и так далее). Я поддерживаю идею, что подсказка доступна для перевода ее в (1) GMT и (2) очевидное местное время пользователя, который видит интерфейс. Смещения полезны также, и также дата, когда полуночные пересечения включены.

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

Бонусное внимание к деталям: Имея дело с временными сдвигами для летнего времени, переходом на летнее время, и т.д., и их различием между местоположениями (не каждое место имеет летнее время, не, каждое место вносит изменение одновременно), и между моментами времени (в будущее особенно).

То, что Вы описали, является ситуацией, где средство просмотра страницы поддерживает клиента.

Таким образом, я рекомендую, чтобы дизайн сфокусировался на клиентской перспективе. Так, значение по умолчанию или метод главного дисплея должно быть местным временем клиента. При использовании электронной почты или IM у Вас должен быть некоторый userdirectory как источник. Если Вы разговариваете по телефону, то идентификатор вызывающего абонента может быть основанием преобразования времени.

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

Это должно также иметь опцию показать местное время при прибытии. Это позволяет Вам разговаривать с клиентом бесшовным и эффективным способом:

CU: "When will it arrive?" 
CS: "Based on your phone number, I am assuming you are in EST. The ETA is 8pm". 
CU: "I am traveling in Chicago right now. Can you tell me when I should check back?"
(Phone rep taps a "CST" button on the screen, and the displays convert.) 
CS: "Sir, if the package does not arrive before 9:10pm, your local time, please call us."

Будучи укушенным несколько раз за эти годы "маленькими" приложениями, внезапно являющимися или в национальном масштабе (в США, 5 или 6 часовых поясах) или глобальный, я всегда храню данные даты и времени в UTC, если это возможно.

Проблема затем становится дисплеем, как указали много других сообщений.

Если дата/время отображена, и она касается местоположения (и локаль) текущего пользователя, отобразите ее в местное время пользователя.

Если несколько, дата/времена должна быть отображена и они касаются различных местоположений (возможно различные локали), я нашел, что пользователи предпочитают видеть время, отображенное в часовом поясе местоположения в 12-часовом формате.

Думайте о том, как авиабилеты печатаются (по крайней мере, в США) - время отправления и время поступления отображены в часовом поясе города прибытия и города отправления. Лучшие маршруты имеют "общее время прохождения" или продолжительность, отображенную также.

Хорошо, таким образом, Вы хотите показать отформатированные данные локали для пользователя: Как Вы определяете локаль? Для веб-приложений, в то время как локаль присутствует в большинстве HTTP-заголовков, Вы не можете всегда полагать, что локаль установлена правильно на машине пользователя. Таким образом, мы почти всегда заканчиваем любая просьба, чтобы пользователь установил профиль, который включает некоторые данные, от которых мы можем определить локаль (почтовый индекс, город/состояние/страна, и т.д.) или ввести что-то, что дает нам общее представление о том, где пользователь на самом деле находится (или для веб-приложений или для 'собственных' приложений)

Я не должен был реализовывать это, так как геолокация через IP-адрес стала широко доступной, но это не обязательно точно также.

Обратите внимание, что, когда я работал над этими приложениями, мои персональные настройки почти всегда заканчиваются в 24-часовом формате, UTC, ISO8601 именно так, который я знаю, во сколько отображается мне, независимо от того, где пользователь.

лучшая вещь сделать состоит в том, чтобы хранить всю информацию даты/времени в UTC и затем отобразить смещение времен к пользовательскому времени..NET имеет все виды поддержки этого - большинство других сред делает слишком в этом отношении. кто-то вводящий данные в Лондон в 7:00 должен показать 1:00 или 2:00 EDT. большая часть о UTC - то, что он избегает всех te странных вещей с временами перехода на летнее время или отсутствием этого, когда Вы находитесь в местах, которые не имеют его, например, Корея, Индия по сравнению с новыми смещениями для Северной Америки.

Мне нравится в 24-й раз, такой как 15:30 EDT, но я уверен, что существует это там что работа в 12-м режиме. сделайте это опцией наверняка.

Всегда отображайте время в UTC

NB я не соглашаюсь с этим. Я просто добавил его как опцию для голосования.