config superset for local time zone?

[Manoj1881]

Make sure these boxes are checked before submitting your issue - thank you!

• I have checked the superset logs for python stacktraces and included it here as text if there are any.
• I have reproduced the issue with at least the latest released version of superset.
• I have checked the issue tracker for the same open issue and I haven't found any solution.

Superset version

superset --version
Flask 0.12.4
Python 3.6.4 |Anaconda, Inc.| (default, Jan 16 2018, 12:04:33)
[GCC 4.2.1 Compatible Clang 4.0.1 (tags/RELEASE_401/final)]

Expected results

querying from superset is still in UTC even after changing DRUID_TZ in config.py to DRUID_TZ = tz.tzlocal()

[srggrs]

I think that when you query Druid with timezone aware, e.g.
{ "granularity": { "type": "period", "timeZone": "Australia/Sydney", "period": "P1D" }, "intervals": "2019-01-25T00:00:00+11:00/2019-02-01T00:00:00+11:00" }

Druid will give back result with this timestamps:

2019-01-25T00:00:00+11:00 xxxxx
2019-01-26T00:00:00+11:00 xxxxx
...

and pandas will convert them to UTC in any case (see https://github.com/apache/incubator-superset/blob/adc9a6b495d42c0e1d35dff5d79ef5534b77a320/superset/viz.py#L197-L241), therefore you need to convert back in the localtimezone, which is not done automatically. The only thing that it is done, it's using a an hour offset defined in the datasource properties, and applied here:
https://github.com/apache/incubator-superset/blob/adc9a6b495d42c0e1d35dff5d79ef5534b77a320/superset/connectors/druid/models.py#L1308-L1330

[Manoj1881]

Thanks for the reply @srggrs
I am in IST with 5 hours and 30 min offset and hour offset is only accepting integers,

I think it should accept float value.

or
the timestamp should be converted back to local.

[TheRum]

@Manoj1881 I am also having same issue. Did you find any workaround to this ?

[med4it]

Same issue, is there any way to change superset timezone from the UI ?

[jpike88]

+1 on this, timezones are important.

[D3nn3]

Agree. We have some edge cases were entities are associated to wrong days (leading to sometimes inaccurate metrics) because of this :/

[jessicaxyl]

+1

[zygeilit]

+1

[zygeilit]

timezones are important

[PedroPini]

+1

[DevHerrera]

+1

[etothexipi]

+1 Daylight savings causes issues where users have to update datasource timezone offset for each datasource twice per year.

[shucle-devops]

+1

[HofmannHe]

+1

[waqasakramef]

Any solution for this?

[liuyong888]

+1

[Usiel]

+1

Would also hope to have some kind of UI element to allow the user to select a timezone, which is then used for any datetime handling and in the currently queried DB's context.

[ishandharzenatix]

SELECT
TIME_FORMAT(__time,'yyyy-MM-dd HH:mm:ss','Asia/Kolkata'),__time
FROM "live-Customers"

Does this solve your problem?

[maratbakiev2]

+1.

[masoncatch]

+1

[ThanhTrung90]

+1
Is there any update for this?

[Bill0412]

Use offset can temporarily solve this problem, the issue is that US has daylight saving.

[rizalsofyans]

+1

[benjaminlhai]

+1

[Stefan781]

+1, I am surprised this hasn't been resolved yet.

[MathijsNL]

+1
To add to the discussion, what kinda works for me is the following with some caveats:

SELECT CONVERT_TZ(NOW(), 'UTC', 'Europe/Amsterdam') as DateTime

This does mean that for data from different timezones you have to either use different datasources or you have to store this info in DB and fetch it so the date will be converted properly.

Also, when using this trick having any date filter that ends with Now there is a possibility that data won't show up for a few hours so you will get delays. Adding a few hours to the end date works but it doesn't feel like a user friendly solution, especially people that have to work with the data from the dashboard.

[william-seaton]

I think this is super important. I think a lot of this is to power BI, which is difficult to do when if I set a chart up to show sales for the last day it shows last day in UTC... this issue is basically the only reason we can't use Superset at the moment over most other BI tools.

I think this is something that just needs to be implemented in the UI. I do not think it needs to go any deeper than what is already there, if Dashboards could just translate time filters and queries from Local time to UTC and charts from UTC to local time then it would solve 90% of the issues.

I see mention that DST would cause issues; however, browsers implement this just fine. Just translating the fields should do it nicely.

[rumbin]

Unfortunately, I think there is more complexity to it:

Dates are also timezone-specific.
So, consider you live in UTC-7 and your query performs a date_trunc('day',...) for showing your daily sales.
And Superset would translate your selected time range to UTC when passing the query to the DB.
Then the DB returns the daily aggregated data in UTC dates. Now, how will Superset convert this back to UTC-7 dates?

Unfortunately, setting the timezone will, in my eyes, always require to push down this shift to the database. This makes the implementation much more complex.

But, I second that there is a big need for this functionality, nevertheless.

[iamsaso]

The relative time selector (e.g., "last day") should consistently reflect the client's timezone. Currently, there is an issue where, for instance, when the date is November 20th, the "last day" option displays as November 20th. Ideally, the "last day" selection should show the date as the 19th, aligning with the client's timezone.

[sebastianknopf]

+1

[shubhshah01]

+1 any update on this?
timezone offset atleast should take in float values to allow all kinds of offset. like IST offset is +5:30 from UTC.

[cybergitt]

Make sure these boxes are checked before submitting your issue - thank you!

• I have checked the superset logs for python stacktraces and included it here as text if there are any.
• I have reproduced the issue with at least the latest released version of superset.
• I have checked the issue tracker for the same open issue and I haven't found any solution.

Superset version

superset --version Flask 0.12.4 Python 3.6.4 |Anaconda, Inc.| (default, Jan 16 2018, 12:04:33) [GCC 4.2.1 Compatible Clang 4.0.1 (tags/RELEASE_401/final)]

Expected results

querying from superset is still in UTC even after changing DRUID_TZ in config.py to DRUID_TZ = tz.tzlocal()

I got reference for this issue that maybe could help.

Apache Superset Backend Timezone

Understanding and configuring the timezone settings in Apache Superset's backend is crucial for ensuring data consistency across different components. Here's a comprehensive guide to help you navigate timezone configurations in Superset's backend.

Timezone Configuration

• Data Timezone: Ensure that the data ingested into your databases has a consistent timezone, preferably UTC.

• Database Engine Timezone: Configure your database engine to match the timezone used for data storage.

• Superset Backend Timezone: By default, Apache Superset assumes that timestamps are in UTC. It's recommended to align the backend timezone with UTC to avoid issues.

• Client Timezone: While the client timezone is beyond Superset's control, the backend sends timestamps with explicit timezones to maintain consistency.

Setting Backend Timezone

To set the backend timezone in Apache Superset, follow these steps:

1. Access the Superset configuration file, typically superset_config.py.

2. Set the timezone configuration to UTC:

from datetime import timedelta
DEFAULT_TIMEZONE = 'UTC'

3. Restart the Superset service to apply the changes.

Handling Timezone in Data Visualization

When visualizing data, it's important to consider the timezone settings:

• Use the Timezone Offset feature in the Edit Dataset view to adjust time columns to the desired timezone.
• Apply timezone conversions in SQL Lab queries when necessary.

Best Practices

• Align all components to use UTC to simplify timezone management.
• Always include timezone information in temporal fields to prevent ambiguity.
• Regularly review and update timezone settings to reflect daylight saving changes or policy updates.

By following these guidelines, you can ensure that your Apache Superset instance handles timezones effectively, providing accurate and consistent temporal data across all visualizations and dashboards.

Reference

Apache Superset Timezone Guide

[garciagaston]

@cybergitt Is there a way to dynamically set the time zone for a dashboard based on the user's local timezone?

[cybergitt]

@cybergitt Is there a way to dynamically set the time zone for a dashboard based on the user's local timezone?

Hi @garciagaston I understand that maybe You need to modify the "look" of date format for the date filter features, to answer this You can try to read again my answer on above, the highlight is "Client Timezone" and "Data Visualization".