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

Question

(Это вопрос об интерфейсе пользователя, а не о технологии, необходимой для этого)

Как проще всего отобразить пользователю время для событий, происходящих в разных часовых поясах? Ваш «средний» пользователь понимает UTC и часовые пояса?

Мы фиксируем местное время и смещение UTC и сохраняем его в базе данных (SQL 2008 DateTimeOffset) для событий, происходящих в разных часовых поясах. Пользователи также находятся в разных часовых поясах.

Я предложу пару ответов ниже, чтобы их можно было оценить, но я буду признателен за альтернативные предложения.

РЕДАКТИРОВАТЬ: я хотел бы избежать отображения времени в часовом поясе пользователя. Пользователи в разных часовых поясах будут обсуждать одни и те же события, и если они локальны для разных часовых поясов, возникнет путаница.

РЕДАКТИРОВАТЬ: Я хотел сделать вопрос общим и, надеюсь, полезным для большего числа людей, но для некоторого конкретного контекста это веб-приложение для отслеживания посылок (например, FedEx). Посылки будут пересекать часовые пояса. Служба поддержки находится в Великобритании, но получатель может быть в другом месте.

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

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

Answer 5

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

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

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

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

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

Answer 6

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

Answer 7

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

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

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

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

Answer 8

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

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

Answer 9

Отображение с сокращением часового пояса

Вместо

15:18 GMT+1

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

15:18 CET 

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

Answer 10

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

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

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

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

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

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

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

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