Which timezone to use for visualizing data?

Question

We have a web app with scientific timeseries data that we show in graphs and such. The data are measurements from many different sensors, often taken every minute or so.

The timezone the user is currently in may not be the same as the timezone the data is from, both because the user may be elsewhere geographically and because we may be looking at winter data in summer (daylight savings).

Which timezone is it best to use when visualizing the data?

• The local timezone of the sensor back when the data was recorded -- this makes most sense when looking back at old data, because then you see high temperatures during the day, etc.

• The local timezone of the user, as it was at the time when the data was recorded (use local wintertime for data recorded in winter) -- most people expect times in a web app to reflect their own local time, but this means the data you see depends on where you happen to be right now.

• Just show UTC always and let the user deal with it, but most of the time the user will actually be in the same timezone as the sensor, usually not UTC.

• Something else.

There probably isn't a single best answer, is there a common practice?

Answer 1

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're showing rainfall and temperature over time in Australia. It'll only make sense to label December as summer even if the viewer is from North America.

For computer/server related datasets where exact time points are important, if the viewer has understanding of what UTC represents, UTC is likely a safe bet for standardizing time because you avoid issues due to time zones and daylight saving time and all that good stuff.

Answer 2

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 data points or X-axis tick marks as Pacific Standard Time (PST) rather than New York’s Eastern Standard Time (EST).

While one could argue that it’s nice to see data translated into your own time zone wherever you are, it’s not convenient to think about building operations remotely from a time zone that differs from the building’s own. Our problem was specific, it was a mission critical visualisation. We had to fix it.

So the answer you're looking for is "it depends". The criterias should be chosen as per your user needs. I'd advise you to analyse the type of information in your graphic, if it was mission critical such as ours then you need to adhere to a standard. If it isn't then be as flexible as possible as it never hurts to give the user an an option for alternative View.

As for javascript plugins that can help you with this, I recommend you look up http://momentjs.com/timezone/

Answer 3

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

Answer 4

It really depends on what is the typical analysis to be performed with the data. If the analysis is local either (e.g. trends in one sensor's measurements over time), or time-agnostic (e.g. comparison of mean values from different sensors) you should stick with local time associated with the recording event, which is the least confusing for the user. Like you said yourself, natural trends like daily temperature cycle will look, well, natural.

However, once you start to consider data across a time window for multiple timezones at the same time, I believe you should go with UTC and let the user do time conversions. The downside of being not-so-natural compared to local time will be compensated by the following advantages:

1. While the mental gymnastic with timezones is hard, the rule itself is simple. All you have to say to the users is "all timestamps are UTC". Whether a particular location is subject to daylight saving (aka summer time) or moves from one timezone to another is not of your concern. And local users know such details better than you do.

2. It's the only way I know to make things consistent. If you stick with local times you're garanteed to have a user asking: "the summary table says there were 24 measurements on that day, but the scatter plot shows only 23, what's wrong with your app?" And no matter how carefully you explain that the summary is calculated across several timezones and its notion of a "day" is different from the scatter plot, such questions will keep popping up.

I was once involved in a project which chose UTC timing everywhere exaclty for the reason of consistency. Since every "measurement" in our case was a person receiving a radiation dose, the statistics had to be consistent no matter what. A signle data point from 23:45 not included in the report because it was carried over to the following day in a local timezone could be seen as an attempt to alter the audit results, with dire consequences to the unfortunate user.