Designing data viz across timezones
I create web-based data visualizations that are used globally across countries and timezones. What looks correct on my screen in Berlin could be shown incorrectly elsewhere, especially when the underlying data includes dates or specific times.
Timezone issues that I have seen before:
- A chart shifts by a day
- A tooltip shows the wrong hour
- A daily metric is off
JavaScript is notoriously tricky when it comes to handling dates. It's better to catch any issues before the client on the other side of the globe sees a broken visualization. Let’s test!
Using DevTools to easily test different timezones in the browser
Luckily, it’s relatively easy to view a website with a data viz in different timezone without changing any system settings or downloading any third-party tools.
In Chrome (or my favorite browser Brave):
- Open DevTools (e.g. via right click on the page and then selecting “Inspect” or via pressing F12)
- Open the "Sensors" panel (e.g. via the DevTool menu with the three dots, then “More tools” and then on “Sensors” or alternatively via opening the command menu with Cmd or Ctrl plus Shift plus P and then typing “Show sensors”
- In "Location", select a predefined city like Berlin, San Francisco, Tokyo or create a custom location
- Reload your browser tab!
Note that this method only affects the current tab; other tabs will continue to use the system's local timezone.
To test data viz in websites in different timezones in Firefox or Safari, you can use browser extensions (time zone spoofing) or environment variables, as both browsers lack a built-in UI toggle for this compared to Chrome.
Let's check that the browser time actually changed
To check that your browser time is now actually different from your local time, you can either test it yourself in the browser console with some lines of JavaScript or use this handy website.
1. With a bit of JavaScript
2. Using a website checker like https://webbrowsertools.com/timezone/
What to actually test
Of course, I don’t test each and every time zone. I develop in my local time zone (GMT+1 or GMT+2). When I code a chart that uses dates and times, I then test the client’s time zone, and then one very far ahead (like GMT+10) and then one time zone very far behind (like GMT-8).
It can be quite tricky to find out if something is really correct or not. These issues rarely look like bugs. Apart from something obviously broken, I check things like:
- Date boundaries: Does something shift to the previous or next day?
- Aggregations: Are daily or weekly values still correct?
- Labels and axes: Do all timestamps make sense in context?
- Tooltips and interactions: Does the detailed view match the overview?
- Relative times: Are values for things like “3 hours ago” correct?
Make timezones part of the workflow
A different timezone is not a random edge case. It affects how users experience your chart, website, or product. When creating a web-based data visualization with dates and times, I think it should be tested for timezone compatibility similarly to how you check different device sizes for responsiveness.
I learned to include timezone testing as a standard step before shipping, not something I only do when something looks off. Switching the location in the DevTools only takes a few clicks once you know it exists. Checking charts, tooltips, and key aggregates is then usually enough to catch issues early.
