The Problem
UPDATE - once enabled in the org Settings panel, you can show users a timezone override dropdown in dashboards (demo here – expected to be available week of May 4th)
Some use cases require flexibile timezone presentation to really get the context of the data point. If you have just a few you can solve that with static timezone converted timestamp fields for each (i.e created_at_utc, created_at_bst, created_at_est) but that can get out of hand as the list grows.
The Workaround: A Templated Filter + Model-Level Conversion
Instead of relying on static conversions, you can build a timezone picker directly into your dashboard using a templated filter and a timezone conversion function in your model SQL.
Step 1: Define a timezone picker filter in your model
filters:
timezone_picker:
type: string
suggestion_list:
- value: America/New_York
- value: America/Chicago
- value: America/Los_Angeles
- value: Europe/London
- value: Europe/Paris
- value: Asia/Tokyo
default_filter:
is: America/New_York
filter_single_select_only: true
Step 2: Apply the conversion in each timestamp dimension
Use a CASE WHEN to detect whether the filter is active before applying the conversion, so the field degrades gracefully when no timezone is selected (update the field reference and specific timezone conversion syntax for your database dialect if you don’t use Snowflake):
dimensions:
created_at_tz:
label: Created At (User Timezone)
type: timestamp
convert_tz: false
sql: |-
CASE WHEN {{your_view.timezone_picker.is_filtered}}
THEN CONVERT_TIMEZONE('UTC', {{ filters.your_view.timezone_picker.value }}, ${your_view.created_at})
ELSE ${your_view.created_at} END
Default Timestamp in UTC
User notices the order is from Minnesota and selects the appropriate timezone to see the order time locally
Key things to know
- The
timezone_pickerfilter can be shared across multiple dimensions and views, as long as it’s included in the topic — you don’t need a separate filter per timestamp. - You will need to update the SQL for each timestamp dimension you want to convert.
- though most modern data warehouses can optimize queries to make this CASE STATEMENT not be too costly, you should test for query performance if operating on excessively large tables.
What’s next
This workaround gives end users a self-service toggle to switch timezones without requiring a new session. A native event-based mechanism to update the user timezone without regenerating a session has been noted as a product request (eta early May 2026).
