You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On a line chart using the advanced analytics with time shift 1 year incorrectly evaluates to 366 days as the delta and as a result shows incorrect data. 2020 is a leap year, parse_human_timedelta given s of 1 year evaluates to 366 days which is correct given that it's doing d - dttm but in run_extra_queries the delta is calculated from 1 year, which gets evaluated to 1 year in the future (366 days) instead of 1 year in the past (365 days).
Related to this issue, in get_data we are doing df2.reindex(combined_index).interpolate(method='time').reindex(df.index), I'm not sure when this is necessary and I think instead of reindexing we should just throw an error if the dates won't match up in df2 and df. I've debugged problems with this in the past and it's really difficult for users to understand if they are doing a comparison that doesn't make sense. If your granularity is month and you are doing a time shift of 52 weeks the dates for actual values and time shifted values don't match up correctly they get interpolated in a way that will change each of the time shifted values. This shifted data ends up being incorrect (but doesn't look off enough to be obvious) which could result in people reporting incorrect information without realizing.
Expected results
Time shift 1 year results in a delta of 365 days.
Actual results
Time shift 1 year results in a delta of 366 days.
How to reproduce the bug
Create a line chart grouping by month
Under advanced analytics add time shift '1 year', calculation type "Absolute Difference"
Check the results against the actual monthly values
Difference numbers using advanced analytics don't match difference in actual values
Environment
(please complete the following information):
superset version: 0.31
python version: 3.6
Checklist
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.
On a line chart using the advanced analytics with time shift
1 year
incorrectly evaluates to366 days
as the delta and as a result shows incorrect data. 2020 is a leap year, parse_human_timedelta given s of1 year
evaluates to 366 days which is correct given that it's doingd - dttm
but inrun_extra_queries
the delta is calculated from1 year
, which gets evaluated to 1 year in the future (366 days) instead of 1 year in the past (365 days).Related to this issue, in
get_data
we are doingdf2.reindex(combined_index).interpolate(method='time').reindex(df.index)
, I'm not sure when this is necessary and I think instead of reindexing we should just throw an error if the dates won't match up in df2 and df. I've debugged problems with this in the past and it's really difficult for users to understand if they are doing a comparison that doesn't make sense. If your granularity ismonth
and you are doing a time shift of52 weeks
the dates for actual values and time shifted values don't match up correctly they get interpolated in a way that will change each of the time shifted values. This shifted data ends up being incorrect (but doesn't look off enough to be obvious) which could result in people reporting incorrect information without realizing.Expected results
Time shift
1 year
results in a delta of 365 days.Actual results
Time shift
1 year
results in a delta of 366 days.How to reproduce the bug
Environment
(please complete the following information):
Checklist
Make sure these boxes are checked before submitting your issue - thank you!
@john-bodley @mistercrunch @betodealmeida
I can work on a fix, just wanted to give a heads up because you have worked on this before and may have some thoughts.
The text was updated successfully, but these errors were encountered: