Tag Info

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

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