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

попробуйте старомодную графику отдела новостей, где у вас есть часы с надписями "Нью-Йорк", "Лондон", "Токио", а затем "Папуа, Новая Гвинея" или где находится ваш конкретный зритель. Вы можете сделать часы аналоговыми или цифровыми или и то и другое.

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

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

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

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

этой статьи иллюстрирует как это сделать в среде Rails.

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

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

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

обратите внимание, что названия лучше, чем сокращения, которые могут быть неоднозначными. Это зависит от вас, чтобы решить, является ли это более полезно сказать пользователь!--3-->здесь время, или что разница из их часового пояса.

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

отобразить его с абревиатурой часового пояса

вместо

15:18 GMT+1

покажите его как центральноевропейское время

15:18 CET 

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

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

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

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

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

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

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

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

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

поэтому я рекомендую, чтобы дизайн сосредоточился на перспективе клиента. Таким образом, по умолчанию или основным методом отображения должно быть местное время клиента. Если вы используете электронную почту или чат, вы должны иметь какой-то userdirectory в качестве источника. Если вы находитесь на телефоне, то caller ID может быть основой преобразования времени.

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

Он также должен иметь возможность показывать местное время в точке прибытия. Это позволяет вам общаться с клиентом в бесшовной и эффективной манере:

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."

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

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

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

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

лучше всего хранить всю информацию о дате / времени в формате UTC, а затем отображать время смещения на время пользователей. .NET имеет все виды поддержки для этого - большинство других сред тоже делают это. кто-то вводит данные в Лондоне в 7 утра должен показать как 1am или 2am EDT. лучшая часть UTC заключается в том, что он избегает всех странных вещей с переходом на летнее время или их отсутствием, когда вы находитесь в местах, где его нет, например. korea, india против The new offsets for North Америка.

Мне нравится 24-часовое время, такое как 15:30 EDT, но я уверен, что есть те, которые работают в режиме 12H. сделайте это вариантом наверняка.

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

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

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

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

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

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

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

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

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

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