20

Make it explicit that the scheduled campaign will run in the LA timezone to reduce any confusion. MailChimp does it quite nicely with their Delivery by Time Zone feature http://mailchimp.com/features/timewarp/


16

The list you refer to contains tons of duplicates. If you look at the list of time zones in Wikipedia you'll find 40 different time zones. Since you were asking for a 80% solution it's safe to cut the list by 12 (the ones with a 30 or 45 minutes offset. That leaves you with "only" 28 options. The list you've shown contains many duplicates. Still you're left ...


15

Times for flights are almost always given as local time in a 24-hour format. https://travel.stackexchange.com/questions/83626/how-to-read-time-of-flight-for-emirates-airline Most airlines use the 24-hour clock system when telling time. They use this system when assigning trip departures, check-in times and other forms of time designation. The 24-...


12

A map with the title "Where are you", and when user selects a zone update a text with current time (to verify) "In your place it is 08:15 AM".


11

Make your decision based on your user's location. So, someone in the USA will see AM/PM times and someone in Qatar will see 24H. Having just one of the two will confuse users of the other region. Edit More information here: Date and time representation by country


9

The user will be expecting it to be, by default, in their time zone. Anything other than this will cause confusion. However as @RizwanJavaid has highlighted, for some markets/projects (and I would say social media is one) it is perfectly well expected to be able to change this.


9

getTimezoneOffset() The simplest solution should be to call getTimezoneOffset() on a every login or page load, and not burden the user. I don’t know why it isn’t working for you; I thought getTimezoneOffset() accurately accounts for geographic location and local DST practice. Maybe you should investigate this some more to understand when, why, and how much ...


9

The best user experience is the one where the user has to think about this stuff as little as possible. Offer the user the ability to specify whichever timezone they deem most appropriate and handle the conversion and calculation in the code. Because your users are mainly in MST, make that the default. download bmml source – Wireframes created ...


8

Use a simple drop down, but pre-populate it with your best estimate for their zone. You can get the zone from the ip, or use javascript. Users will rarely have to change the selection. When it comes the the actual formatting of the list, i would recomend that you look at windows (or mac). They use conventions people understand. You may also allow users ...


8

People who are used to the am/pm format will be able to correctly understand the 24:00 format. People who are used to the 24:00 format will occasionally misunderstand 12:00 pm. Even people who are used to am/pm will occasionally misunderstand 12:00 pm. So if context doesn't clarify if we're talking midnight or noon, and it's important to avoid ...


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


5

Always record dates and times in UTC especially when working across time zones. Display dates and times in the user's own time zone. Even when you record everything in UTC, what does "today" mean? Usually people mean it to be somewhere between today at 0:00 and today at 23:59:59. Which immediately has implications for someone in another timezone, even with ...


4

I would display 1 primary timezone (by geolocation as mentioned above, or by any other parameter), and provide easy access to the rest. Sunday, January 1st | 1:00 PM EST (more timezones)


4

You may be trying to solve the wrong problem. I would try to select a sensible option for the user or at least filter the list or before reducing or editing options. As suggested in other answers you should be able to do this through javascript or GeoIP detection.


4

UTC became the official standard back in 1972. It's also based on atomic clocks and takes into account the necessary leap seconds every few years. GMT is a time zone. I'd always go with UTC, though, as you mention, as long as you're consistent ... Note: StackExchange goes with UTC.


4

Keep everything to local time of that time zone. With a note such as - This will work as a clear message to the users as what they are looking at; without much time calculations. If California is 12:30 hours behind India; a user in India surely won't expect new data from California. It's similar to what Google does to show tennis time table:


3

Daylight Saving Time is, in some cases, signified by different labels depending on the time of year. For example, Daylight Saving Time in The United States uses the following: Time Zone Standard Time Daylight Saving Time Eastern Time Zone EST (UTC-5) EDT (UTC-4) Central Time Zone CST (UTC-6) CDT (UTC-5) Mountain ...


3

The request initiator and final consumer of the service is a hospital. So it's better to use hospital local time for shedulling in the system. Call center works at other time zone, so you need easy mapping tool for setting Hospital request into Call center time. Admin time has a little meaning in the system, it is more the source of errors. As mapping ...


3

I often find myself one time zone away on trips, and dealing with my calendar on OS X or Windows Office is a mine field. I can summarize the problem as "too many choices": The calendar programs all try to do something clever, and not only do they not do what I need but I never quite know what to expect. Configuration options only make matters worse, because ...


3

If this problem is being solved for a website, and its about displaying some event time in local time for every user, then you may like this solution: we never ask our users to enter thier timezone. Instead we store time in UTC and convert it to local time automatically when it come to displaying data. This conversion has to be done on client side since ...


3

Assuming the DST flip is at 3am based on your example (isn't from 12a - 1a?), you can't know which 3a someone means if they log that time. They could come in at the 2nd 3am (after the switch) or arrive at the first (before the switch). When that time overlaps the DST changeover, you need to prompt them with something like: some sort of flag to indicate -1/+...


3

Specifying the timezone directly in the timestamp is neither good nor bad practice. The answer to your question has more to do with your user experience than any documentation or timestamp formatting. You stated one or more of your users requested the timezone be added to your timestamps. This would imply your timestamps are currently ambiguous, which is ...


2

Put a multiple options for one timezone. -8 Pacific time -8 Los Angeles and so on.. Let users choose based on big cities and timezone.


2

Is there one timezone where the event is taking place? Can you do something like... download bmml source – Wireframes created with Balsamiq Mockups If you're listing this many, it may be better to spell out "Eastern" and "Central" as otherwise, it gets kind of acronym heavy. P.S. If you want to get really into it, you'd use EDST, since not everyone ...


2

The question is why bother ? Why dont you use geolocation or ip tracking to determine where the person is located (in what time zone) and then just display the time zone for that area Should the Day & Date be on a separate line from the times displayed ? - Yes ,just for easier readability, I would recommend posting the date first and then the time since ...


2

The most user friendly approach would be to determine the users time zone for them. One less field for a potential user to fill out. Take a look at this project: https://bitbucket.org/pellepim/jstimezonedetect It uses JavaScript to determine the machines time zone. It provides an identifier like 'America/New_York'. When a user creates an account, get ...


2

If it's an international event, you should show two times: The time and timezone where the event will take place, and the time in UTC (Not GMT, which may include daylight savings). Those are the easiest for anyone to relate to, and any minimally educated person should be able to convert from UTC to their local time zone. If you really need to show only one ...


2

Send an email with a properly formatted .ics file attached. Any reasonably good email client (Outlook, Gmail, etc.) will read the file and turn it into a calendar entry for the recipients time zone. Attached is an example generated by creating a Google Calendar event, and sending an invite to an email account on an Exchange server. The sender and recipient ...


2

You try your best in displaying the times in the time zones users are expecting to see the data in. For most scientific datasets, the viewer is trying to understand patterns from the data of a particular region. In this case, the viewer's time zone is irrelevant. Display data using time zone of the region where it's captured. To use an extreme example, you'...


2

Revisited this question again and I think Google has done a pretty good job. Timezone is first narrowed down by country. https://support.google.com/calendar/answer/37064?hl=en


Only top voted, non community-wiki answers of a minimum length are eligible