Create a timezone picker for your end users

Modeling
1

The Problem

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

Screenshot 2026-04-22 at 1.59.08 PM
Screenshot 2026-04-22 at 1.59.08 PM2126×536 38.7 KB

User notices the order is from Minnesota and selects the appropriate timezone to see the order time locally

Screenshot 2026-04-22 at 1.59.18 PM
Screenshot 2026-04-22 at 1.59.18 PM2110×586 40.1 KB

Key things to know

  • The timezone_picker filter 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.

2 Likes