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

Отобразите местное время и смещение, как это 15:18 GMT + 1

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

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

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

Вместо

15:18 GMT+1

Показать как центральноевропейское время

15:18 CET 

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

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

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

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

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

Это подразумевает возможность получить часовой пояс пользователя или сохранить этот часовой пояс в «пользовательской» таблице.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы описали ситуацию, когда зритель страницы поддерживает клиента.

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

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

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

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

Вы упоминаете пакеты. В логистике принято всегда отображать местное время, которое ИБП и т.п. показывают в истории состояний в своих данных отслеживания и отслеживания.

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

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

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