11

In a number of the apps I design, the relative time from now is the preferred time reference. E.g. 'last updated 10 mins ago'.

When it comes to events or broadcast from a location this becomes less straight forward. My preference is to always deal in user's time, e.g. event 'starts in 1 hr' or 'next Saturday at 5 pm'.

My question is in which cases would it be valuable for users to see the timezone and how best to term it to match the existing tone.

Improve this question

5 Answers 5

Reset to default
3

Besides events mentioned in questions, I define some other event classes:
Local event – event, which takes place in some location and requires physical presence (conference) or online within the same timezone area (team communication in the same city)

Worldwide event – event which involves worldwide audience (webinar, online auction)

There is also Mixed event, which actually includes both local and worldwide event (Olympic games openning and its online translation, conference announce and tickets selling)

The rule of thumb for using dates and times is:

  • for Local events use local event date and time, not user local time
    single date is consistent among international users, there are no confusing while moving to other time zones. The event location (i.e. London) creates reference to appropriate time zone so it is easy to calculate user local time, although it is not usefull.
  • for Worldwide events use timezone designators and optionally starting or expiration relative time (in days/hours/minutes)
    as there is no event physical location (for online users) and users all over the world could participate such events use time zone designitors. It could be converted to user local time but this requires additional server side or client side processing (native toISOString() function or moment.js library) and is not 100% guaranteed (wrong client time, non-working javascript etc.). Time zone reference allows easy convert to user local time manually or with online services.

Some examples of the rule usage:
Mixed event: local (conference announce) and worldwide (online ticket refund)
enter image description here

Worldwide events – webinars
enter image description here

Local event – conference
enter image description here

Mixed event: local (conference) and worldwide (ticket selling) enter image description here

Worldwide event with expiration time – online auction
enter image description here

So you can see the time zone designators are used rather wide.

Improve this answer
4
  • UTC time has no value for me or the majority of users. Unless you live in Western Europe, the required translation to local time is difficult and completely unnecessary.
    – quietmint
    Aug 11, 2013 at 17:42
  • UTC time (with time zone specification) is international standard and the fact is it is widely used, look at my examples. What I did was analysis of UTC time usage cases. The result is the empirical rule. I agree, translation brings some frictions, but this is just a compromise in the world divided on time zones.
    – Alexey Kolchenko
    Aug 11, 2013 at 18:11
  • Not a single one of your examples shows a UTC time. :-) I don't dismiss that UTC is a well-established standard, I just contend that it is absolutely useless from a usability perspective. Average Joe doesn't (and shouldn't) deal with UTC times in their daily life. There's no reason to push timezone translation onto the user. Even without automated detection, a user-controlled preference in the app's profile/settings page can easily avoid this nonsense.
    – quietmint
    Aug 11, 2013 at 18:19
  • Sorry, you are right about UTC technically. Under UTC time (with time zone) I meant time zone designators, i.e. offset from UTC. The question was about displaying timezone. Abbreviations like "EST, WST, CST" are time zone designators and they are widely used. But they are definitely not UTC, as you pointed ). Thanks for clarification!
    – Alexey Kolchenko
    Aug 11, 2013 at 19:19
6

Unless you are displaying a time with location information, I would just display it consistently in the local time zone.

Example 1: Check-ins

This is an example of where you WOULD want to show it in the specific timezone.

If you are displaying check-ins on a map. You would want to show the times in the relevant timezone. However, if you are a trying to establish a timeline around the viewer, you would provide either local times or the relative time.

–– CHECK-IN ––––––––––––––––––––––––––––––– 1 day ago ––
Location: New York, NY
Time: 8:15am (EST) on Tuesday

–– CHECK-IN –––––––––––––––––––––––––– 32 minutes ago ––
Location: San Francisco, CA
Time: 9:28am (PST) Today

–– UPCOMING EVENT –––––––––––––––––––––––– in 2 hours ––
Location: Dallas, TX
Time: 2:00pm (CDT) Today

Example 2: User Comments

This is an example of where you WOULD NOT want to show different timezones:

–– Comment by Joe ––––––––––––––––––
3:45pm
"This is great!"

–– Comment by David ––––––––––––––––
4:00pm
"I agree."

Using a consistent timezone for display values in this case is important for maintaining a clear timeline.

Additional Information

Naming Conventions fall under the Interaction Design (IxD) vertical. There are some good principles here that might help offer some insight.

Chris Dixon just shared some thoughts about display timezones recently as well.

Improve this answer
5
  • 1
    Great answer. To add: a site with news articles from all over the world would still have it in the current time, because the time represents the blog post, not the news. In the articles themselves, I'd use GST and the like, though, because you're talking about the events.
    – Dirk v B
    Aug 8, 2013 at 5:25
  • @Kiorrik: what is GST? I know GMT and GMT daylight savings time. Which, by the way I wouldn't use in the articles themselves. If something is about Taiwan, use local Taiwan time in the article. It would be strange to read about something that happened in the morning (local time) with a time that on first glance puts it in the middle of the night.
    – Marjan Venema
    Aug 8, 2013 at 6:52
  • Oh rats. GST is Australian goods and service tax. I meant GMT. Got my acronyms mixed up. Lack of caffeine will do that to ya. .edit: after some research, it also happens to be Gulf Standard Time. Live and learn.
    – Dirk v B
    Aug 8, 2013 at 7:21
  • In example 1 I have the location and local time of check in. If I want to use a time reference relative from now how would it work? I'm thinking of a notice like '@DesignerGuy should be checking in at NYC in 40 mins'
    – micap
    Aug 8, 2013 at 8:16
  • @DesignerGuy - while your answer was informative and valuable. The answer by Alexey Kolchenko more closely answers and complements the posed scenarios.
    – micap
    Aug 17, 2013 at 11:17
0

The thing is very simple. If your news/event has global users then you should display time with Timezone. For example if you send a meeting request to your attendees in another country where the time zone differs from your Timezone then you always mention the Timezone with time. EX. March 10, 2014 14:30 PST OR March 10, 2014 2:30pm PST

OR if you have only domestic users then it is good to display only time. EX. March 10, 2014 14:30 OR March 10, 2014 2:30pm

Improve this answer
0

My employer (a company with a worldwide presence) has this problem. They quote Pennsylvania time exclusively and make no effort to translate it into anything more meaningful anywhere else.

Most people who have to deal with timezones do know what GMT is (or maybe UTC) and can translate GMT into local time. The principal problem is identifying the correct offset in the multiplicity of available timezone abbreviations and then calculating the local time correctly. There are several sources of error, all of which may be compounded. What is CEST? Does ET include the hour for summer time? Is EST Eastern Standard Time or Eastern Summer Time?

A reasonable solution is to say

Starts at 1pm EST (6pm GMT)

and let people in Asia, or Central Europe, or Britain on summer time, work it out from there.

A better method, particularly in browsers, is to use Javascript [or perhaps server-side or web-based utilities] to calculate the local time zone and add that, if the information is available:

Starts at 1pm EST (6pm GMT) (11:30pm in your time zone)

Improve this answer
1
  • Calculating time isn't a problem in this case because these are designed for native mobile apps which can query device time locale. But thanks for adding further info for browsers
    – micap
    Aug 15, 2013 at 22:17
-1

I tend to think that taking a line from tv networks would be useful here

"Saturday at 5pm (6pm ET)"

It would serve the purpose of providing the user a time conversion, but will still give them the actual time of the event. I think it's quite clear this way.

Improve this answer
1
  • This works well, because they are displaying all showtimes that way, but if you used this format in different timezones it could seem really confusing.
    – Andy Fleming
    Aug 8, 2013 at 19:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.