Design Timezone and Locale Aware Data

Data & Dashboards · internationalization, tables, dashboards

Updated 2026-07-28

Decide whose clock the product runs on and say it out loud. Teams working across regions will otherwise argue about numbers that are both correct.
State the timezone on every report, chart, and export. A daily total is a different number depending on where the day starts.
Let users choose between their own timezone and the account's, and keep the choice visible rather than hiding it in settings.
Watch the boundaries that silently corrupt reports:

Where the day starts for daily aggregates.
Which day a week begins on.
Daylight saving changes, which produce one short day and one long one every year.
Fiscal periods that do not match calendar months.

Never compare periods across a timezone change without saying so. A week that is one hour shorter looks like a real decline.
Keep exports unambiguous. Include the timezone in the file, in the filename, or in a header row, because a spreadsheet will reinterpret bare timestamps.
Format for the reader's locale and sort by the underlying value. Localised text that sorts by its display form produces nonsense ordering.
Show the raw value somewhere reachable, so anyone reconciling two systems can see what is actually stored.

Time is the most common source of two people looking at the same dashboard and seeing different truths.