richardcrist opened a new issue, #35422: URL: https://github.com/apache/superset/issues/35422
*Please make sure you are familiar with the SIP process documented* [here](https://github.com/apache/superset/issues/5602). The SIP will be numbered by a committer upon acceptance. ## [SIP] 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. <img width="407" height="568" alt="Image" src="https://github.com/user-attachments/assets/c86354e6-1615-4514-9e3c-3f8b94df29a8"; /> ### 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: <img width="1287" height="208" alt="Image" src="https://github.com/user-attachments/assets/2fa6e833-1052-4478-9905-bdb08716e251"; /> In Superset it could be placed similar: <img width="1307" height="909" alt="Image" src="https://github.com/user-attachments/assets/f01f5e2a-6f20-4a0e-9685-9dbe9e21e570"; /> ### 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](https://github.com/vvo/tzdb) [2](https://www.[npmjs](https://www.npmjs.com/package/@cicatriz/timezone-toolkit).com/search?q=keywords%3Atimezones+list) [3](https://stackoverflow.com/questions/66490421/valid-iana-timezone-list) [4](https://www.npmjs.com/package/countries-and-timezones) [5](https://classic.yarnpkg.com/en/package/countries-and-timezones) [6](https://www.npmjs.com/package/@cicatriz/timezone-toolkit) [7](https://[pypi](https://pypi.org/project/tzdata/).org/project/tzdata/) [8](https://docs.python.org/3/library/zoneinfo.html) [9](https://peps.python.org/pep-0615/) [10](https://pypi.org/project/pytz/) [11](https://stackoverflow.com/questions/73727629/dynamic-setting-the-timestamp-fields-in-superset-dashboards) [12](https://www.npmjs.com/search?q=timezone) [13](https://github.com/apache/superset/discussions/19176) [14](https://day.js.org/docs/en/timezone/timezone) [15](https://superset.apache.org/docs/configuration/timezones/) [16](https://www.npmjs.com/ package/date-fns-tz) [17](https://gist.github.com/dineshsaini/69dc28c8a5258808cfe5e1c17433972c) [18](https://socket.dev/npm/category/utilities/regional/timezone) [19](https://www.iana.org/time-zones) [20](https://superset.apache.org/docs/configuration/databases/) ### 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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
