Skip to content
This repository was archived by the owner on Dec 10, 2021. It is now read-only.

Calendar heatmap dates shifted by one (converting to local time zone) #409

Closed
3 tasks done
ghost opened this issue Apr 28, 2020 · 10 comments
Closed
3 tasks done

Calendar heatmap dates shifted by one (converting to local time zone) #409

ghost opened this issue Apr 28, 2020 · 10 comments
Labels
#bug Something isn't working

Comments

@ghost
Copy link

ghost commented Apr 28, 2020

move[bot] commented on Apr 10, 2019, 4:33 PM UTC:

hyperborea commented on Jan 8, 2019, 5:17 PM UTC:

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 issue and I haven't found one similar.

Related to #3326, which is closed but has not been resolved.

Superset version

0.28.1

Expected results

Time is displayed consistently in the same time zone on the calendar heat map as for the data queried. The January day view should start with the 1st of January for example.

Actual results

The January day view starts with the 31st of December 23:00 for setups using CET. The data is queried correctly in UTC, but somehow seems to be displayed in local time zone instead.

Steps to reproduce

  • create calendar heatmap
  • configure with "day" time grain, "month" domain and "day" subdomain
  • observe months starting with the previous months day for time zones east of GTM and all days shifted accordingly

This issue was moved by kristw from apache/incubator-superset#6619.

This issue was moved by kristw from apache-superset/superset-ui-plugins#52.

@ghost ghost added the #bug Something isn't working label Apr 28, 2020
@ghost
Copy link
Author

ghost commented Apr 28, 2020

move[bot] commented on Apr 10, 2019, 4:33 PM UTC:

stale[bot] commented on Apr 10, 2019, 9:59 AM UTC:

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@ghost
Copy link
Author

ghost commented Apr 28, 2020

@lewlh commented on Apr 24, 2019, 2:26 PM UTC:

I have the same problem。

@ghost
Copy link
Author

ghost commented Apr 28, 2020

@priyajos commented on Sep 26, 2019, 6:00 AM UTC:

I have the same problem。

@ghost
Copy link
Author

ghost commented Apr 28, 2020

@karbofoko commented on Nov 12, 2019, 3:23 PM UTC:

have the same problem, any plans to fix this?

@ghost
Copy link
Author

ghost commented Apr 28, 2020

@karbofoko commented on Nov 12, 2019, 6:30 PM UTC:

it seems dates are shifting only in the tooltip, rest logic works fine (days of the week, values by dates).
Shifting date back before formatting in the tooltip fixed problem for us:
${self.options.timeFormatter(d.t + 24*60*60*1000)}:...

| | ${self.options.timeFormatter(d.t)}: ${self.options.valueFormatter(d.v)} |

don't forget to reset browser cache

@ghost
Copy link
Author

ghost commented Apr 28, 2020

@dofine commented on Mar 17, 2020, 9:12 AM UTC:

Any progress on this, please?

@xcoder123
Copy link

We noticed this problem as well after the summer time ended

@mjasin
Copy link

mjasin commented May 6, 2021

Any progress on this?

@spartyann
Copy link

Hello, i have this problem using "day" as domain and "hour" as subdomain.
Mariadb data source stores the dates in UTC+0. I am in France with UTC+2. And in the Calendar Heatmap I get an offset of 4 hours. This is very annoying.
Thanks a lot!

@villebro
Copy link
Contributor

The codebase on this repo has been moved to the main Apache Superset repo, and consequently the repo is in the process of being archived. See the Superset Improvement Proposal for details: apache/superset#13013 . While all currently open issues and PRs will be closed, we encourage you to reopen this issue on the main repo if it is still relevant.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
#bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants