Please make sure you are familiar with the SIP process documented here. The SIP will be numbered by a committer upon acceptance.

[SIP-186] Proposal for User Timezone Selection

Motivation

Currently, I am in Central time zone, but our Superset server and application (appropriately) use UTC time zone. All our dates in table data are also stored in UTC. Currently if user selects "current day" in time range filter, then at 7pm Central time it changes selected date from current date to my next day date, because the time range filter is on UTC time. This can cause confusion because user does not know nor see this behavior, only the underlying SQL queries referencing from and to dates via jinja templating see that the date has changed. Suddenly the user gets no data or unexpected data as time range has shifted to next day from user point of view in Central time.

Proposed Change

Proposal is to make available to user a time zone selector, such that when they use a time range filter, all selections they make are assumed to be in that time zone. That way if they select something like "current day", then the resulting time range will be from "day at midnight" to "day+1 at midnight" and will not shift day until midnight their local time. All other relative time options such as "last" will also work correctly per their time zone. Also, it would be good if the user time zone selector functionality could also be available in an automated fashion somehow. Example: User already selects, via custom interface within Superset, a warehouse, which implies a time zone. When user selects a warehouse, then it would be good to be able to programmatically set the user time zone to match warehouse time zone. Then when user selects time range in filter it will match what they are expecting for time zone.

Image

New or Changed Public Interfaces

Describe any new additions to the model, views or REST endpoints. Describe any changes to existing visualizations, dashboards and React components. Describe changes that affect the Superset CLI and how Superset is deployed.

User facing browser page would offer selection of time zone, maybe in top right similar to how Airflow does it:

Image

In Superset it could be placed similar:

Image

New dependencies

Describe any npm/PyPI packages that are required. Are they actively maintained? What are their licenses?

Not going to lie, I went to AI for this:

To enable user selection of standard time zones (like "America/Chicago") in a Superset time range filter, these npm and PyPI packages are recommended for providing a dropdown of IANA time zone names:

Node.js/NPM Packages

  • @vvo/tzdb: This package provides a comprehensive, always up-to-date list of IANA time zone names and related metadata. It is widely used for generating dropdowns and supports direct retrieval of time zone names such as "America/Chicago".[1][2][3]
  • countries-and-timezones: Another popular package allowing lookup and listing of all IANA-compliant time zones, with extras like country associations.[4][5]
  • @cicatriz/timezone-toolkit: Provides functions to list all IANA time zones or filter them by region (e.g., "America", "Europe").[6]

Python/PyPI Packages

  • tzdata: A PyPI package that brings the IANA time zone database into Python environments. It's used as a data source for time zone info.[7]
  • zoneinfo (Python 3.9+ standard library): Built-in support for IANA zones, using system or tzdata-provided data; can enumerate all valid IANA zone names.[8][9]
  • pytz: Allows access to the full set of IANA time zone names via pytz.all_timezones, supporting "America/Chicago" style identifiers.[10]

How These Fit Your Superset Proposal

  • On the frontend (JavaScript/React): Use either @vvo/tzdb or countries-and-timezones to generate selectable time zone lists in the UI.
  • On the backend (Python/Flask): Use zoneinfo, tzdata, or pytz to validate, interpret, and convert user-entered time zones.

All of these packages ensure the user can select any official time zone in IANA's canonical "Region/City" format.[4][1][7][10]

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Migration Plan and Compatibility

Hopefully none if the user time zone selection can be stored as cookie locally.

Rejected Alternatives

I have tried to make use of every existing possible feature in current Superset version 5, but nothing is consistent or foolproof solution. In our data tables we store dates in UTC but in same data row also record the timezone. We can convert the UTC data from table into corresponding time zone, then compare to user time filter selection. Thing is, user knows which time zone of their selected data. If user selects completely manually entered from and to, regardless of Superset UTC default, we can assume the user is specifying date and time values in the desired time zone. This works fine for our purposes. However, if user selects a non-specific selection for from or to, such as "current day", "last", etc., then the resulting date and time is in UTC and will not be what user expects. Currently only way to be sure is request that the user only use manual date and time selection with no non-specific type of entry. There is no way to remove relative non-specific options.

Comment From: rusackas

FWIW, there's an "Hours Offset" feature in the Edit Dataset modal. That might be helpful to a lot of people, but the use cases vary. I assume this would override such a setting/display? Is this something that a more global config for time/UTC offset could handle? Then at least multiple users aren't seeing different times in things like remote work situations.

Comment From: rusackas

CC @mistercrunch @kasiazjc for some initial input here (they've put in some thought on this previously)

Comment From: swathimudda

FWIW, there's an "Hours Offset" feature in the Edit Dataset modal. That might be helpful to a lot of people, but the use cases vary. I assume this would override such a setting/display? Is this something that a more global config for time/UTC offset could handle? Then at least multiple users aren't seeing different times in things like remote work situations.

@rusackas We use the hours offset feature currently, however the lack of timezone information display that would indicate this change causes a lot of problems for us when dealing with a lot of datasets between people in the team working across timezones. I started discussion about this here. Since TimezoneSelector already exists as a component, I think it is worth exploring wiring this into charts and dashboards and adding a feature to display the timezone information in filters and metadata to implement a per user end-to-end timezone handling solution.

Cc @msyavuz

Comment From: richardcrist

Team(s) thank you very much for your response and feedback on this. I feel the TimezoneSelector as a UI feature would be good to set the timezone from user point of view, as our data is in UTC but we track the corresponding timezone. With user selected timezone that correctly generates relative dates based on "current day", "now", "last", etc. user could specify in their timezone either explicit times or relative times, then we could reliablly expect correct user time zone times passed to jinja template, then we could reliably convert user time frames to UTC to compare to our UTC data, or convert our UTC data to user time zone, either direction would work. Key starting point is that user can select time zone to correctly generate explicit time from and to which are passed to jinja, allowing user experience to be in their time zone but reliably filter data.

Comment From: rusackas

This most definitely ties into (but might not be dependent on) the User Preferences SIP, which is a bit further down the roadmap