How Do You Choose a Useful Dashboard Time Zone?
From the earlier reference collection. Read the current software blog.
Choose a time basis that suits the reader’s task, state it clearly, and preserve unambiguous timestamps for cross-region comparison.
Choose the time basis readers need
A dashboard about a local service often makes local civil time easiest to understand. A system monitoring events across several regions may benefit from a shared standard time so readers can compare records without mentally converting each one. The right choice depends on the task, but it must be explicit and consistent.
For example, a transit dashboard for one city might show departure times in that city’s local time, while a cross-region incident timeline might use UTC. If the dashboard switches time basis between views, label each view directly and explain the switch. Do not assume that a location name alone tells every reader which clock is being used.
Handle daylight changes explicitly
Local clocks can move forward or backward when daylight-saving rules change. On the autumn transition, a clock time such as 01:30 can occur twice. On the spring transition, some local times do not occur at all. If a dashboard stores only a local timestamp without an offset or other disambiguating detail, the record can become unclear.
Use a representation that preserves enough information to identify the instant, such as a timestamp with an offset, and show local time for readability where appropriate. In a table, include the date and time zone in the heading or caption. When two repeated clock times appear, make their offsets or sequence clear.
Make conversions visible
When readers can select a time zone, indicate which one is active and update timestamps consistently across the chart, table, tooltips, and download. A conversion should not change the underlying event, only its displayed clock time. Keep a stable timestamp or offset in exported records so another tool can interpret the instant correctly.
A reader comparing an alert at 16:00 UTC with a local reading at 09:00 Pacific time needs to know whether daylight time is in effect and whether both values refer to the same date. Showing the zone beside the time makes that check possible.
Document the source convention
Source data may already use a specified time basis, and it is helpful to preserve that information in the method note. Explain how the dashboard converts source times, how it handles ambiguous local times, and whether daily summaries follow calendar dates in the displayed zone. Clear time-zone labels prevent apparent gaps, duplicated hours, and mistaken comparisons.