Hot answers tagged time-zones
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/
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.
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 ...
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 ...
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 ...
Have you asked what your users expect to see? For example, I would say that it is ok for the date to be stored in UTC in the database, but your users might expect to see the time stamps based on their time zone (which might be taken from their user profile page).
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.
Most users are going to be more familiar with the names of major cities nearby than with all the various abbreviations for time. (Plus it gets confusing when for example we have GMT, and UTC, which are probably the same, but even I'm not certain if during British Summer Time (BST), Britain becomes GMT+1, or if GMT becomes UTC+1. I know that Britain is GMT, ...
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, ...
It depends on the other timestamps you display on your site/app. However, timestamps are almost always used to compare events relatively in a single timeline, so in almost always, it's better to stick to one timezone. Give the user an option to select their timestamp. Always load the user-selected time zone, and convert all timestamps to that timestamp. ...
Possibility: Pick a timezone by default (e.g., UTC) and then have a way for the user to choose a different timezone to use. (Or, ask the user for the timezone first, or have that timezone as a preference in their user settings that they can change.)
Plotting data with non-local timezones was a problem in one of the projects I engineer'ed at. Soon after the product's launch, we noticed a problem when we viewed data about buildings in New York from computers in California that had never surfaced in our automated testing or manual QA efforts: all of our charts for New York buildings displayed times on ...
Only top voted, non community-wiki answers of a minimum length are eligible