-
Notifications
You must be signed in to change notification settings - Fork 14.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug fix] Divide by 1000.000 in epoch_ms_to_dttm() to not lose precision in Presto #5211
Conversation
… timezone info; use it as UTC
…es annotations are applied based on the updated chart object after adding all data
…es annotations are applied based on the updated chart object after adding all data
…m/tc-dc/superset into evelynturner/annotation_range_fix
…c/superset into evelynturner/timeseries-fix
@evelynturner I'm not sure this is necessary given that dividing an integer by a float returns a float, i.e.,
works as expected. |
@john-bodley That's because of your
https://prestodb.io/docs/current/language/types.html#floating-point I can always set it as true, but I didn't see any harm in accommodating to the other setting as well. Maybe we can document it somewhere that people need to set those properties as |
LGTM though can you rebase? |
…erset into evelynturner/prestofix
Codecov Report
@@ Coverage Diff @@
## master #5211 +/- ##
===========================================
- Coverage 77.48% 61.32% -16.16%
===========================================
Files 44 369 +325
Lines 8749 23488 +14739
Branches 0 2717 +2717
===========================================
+ Hits 6779 14405 +7626
- Misses 1970 9071 +7101
- Partials 0 12 +12
Continue to review full report at Codecov.
|
…ion in Presto (apache#5211) * Fix how the annotation layer interpretes the timestamp string without timezone info; use it as UTC * [Bug fix] Fixed/Refactored annotation layer code so that non-timeseries annotations are applied based on the updated chart object after adding all data * [Bug fix] Fixed/Refactored annotation layer code so that non-timeseries annotations are applied based on the updated chart object after adding all data * Fixed indentation * Fix the key string value in case series.key is a string * Fix the key string value in case series.key is a string * [Bug fix] Divide by 1000.000 in epoch_ms_to_dttm() to not lose precision in Presto * [Bug fix] Divide by 1000.000 in epoch_ms_to_dttm() to not lose precision in Presto
…ion in Presto (apache#5211) * Fix how the annotation layer interpretes the timestamp string without timezone info; use it as UTC * [Bug fix] Fixed/Refactored annotation layer code so that non-timeseries annotations are applied based on the updated chart object after adding all data * [Bug fix] Fixed/Refactored annotation layer code so that non-timeseries annotations are applied based on the updated chart object after adding all data * Fixed indentation * Fix the key string value in case series.key is a string * Fix the key string value in case series.key is a string * [Bug fix] Divide by 1000.000 in epoch_ms_to_dttm() to not lose precision in Presto * [Bug fix] Divide by 1000.000 in epoch_ms_to_dttm() to not lose precision in Presto
Context:
In an unfortunate event where the entry is < 1 second from the next day, the generated query casts it to the next day. This shouldn't be a problem in MySQL, but it is in Presto.