You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@superset.apache.org by GitBox <gi...@apache.org> on 2022/01/18 12:37:41 UTC
[GitHub] [superset] polmonso opened a new issue #18079: The union of two timestamptz changes the time of the stamps
polmonso opened a new issue #18079:
URL: https://github.com/apache/superset/issues/18079
The union of two timestamptz changes the time.
#### How to reproduce the bug
Go to sqleditor and run
```
select '2022-01-17T00:00:00+01:00'::TIMESTAMPTZ
UNION
select '2022-01-18T00:00:00+01:00'::TIMESTAMPTZ
```
this produces
```
timestamptz
2022-01-16T23:00:00+01:00
2022-01-17T23:00:00+01:00
```
instead of
```
timestamptz
2022-01-17 00:00:00+01
2022-01-18 00:00:00+01
```
Without the union the timestamptz is displayed correctly.
If the query is ran directly on postgresql it is displayed correctly.
This is more than a timezone display bug because `2022-01-16T23:00:00+01:00` and `2022-01-17 00:00:00+01` are different times.
Our guess is that since superset uses pandas internally, pandas doesn't handle datatimes with non-utc timezones very well and sometimes defines the column as 'object' instead of datetime[ns,UTC]. However, the superset must be doing something more wrong because the displayed time is not even the same input string anymore since the timezone offset is there but also applied on the time, as if it were mixing a conversion to UTC and using the original timezone offset when printing.
### Environment
(please complete the following information):
- browser type and version:
- superset version: `1.3.2`
### Checklist
Make sure to follow these steps 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.
- [x] I have reproduced the issue with at least the latest released version of superset.
- [x] I have checked the issue tracker for the same issue and I haven't found one similar.
### Additional context
Add any other context about the problem here.
--
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: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
[GitHub] [superset] rumbin commented on issue #18079: The union of two timestamptz changes the time of the stamps
Posted by GitBox <gi...@apache.org>.
rumbin commented on issue #18079:
URL: https://github.com/apache/superset/issues/18079#issuecomment-1019082226
What timezone is your Superset installation set to?
I.e., what is the session timezone of Superset's connection to Postgres?
Not quite sure yet, but I suspect that it has to do with Postgres' timestamptz type which is represented internally as UTC and which only gets translated to/from the session timezone upon querying.
You might want to try a client like DBeaver where you can set the session timezone. Then run the above code while using different timezone settings.
--
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: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org
[GitHub] [superset] polmonso commented on issue #18079: The union of two timestamptz changes the time of the stamps
Posted by GitBox <gi...@apache.org>.
polmonso commented on issue #18079:
URL: https://github.com/apache/superset/issues/18079#issuecomment-1019901029
It's on Europe/Madrid
```
show timezone;
'Europe/Madrid'
```
We can of course change that, but superset should behave correctly regardless since postgres will return the timezone with the data. Changing the database default timezone to UTC would be a workaround.
--
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: notifications-unsubscribe@superset.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org