-
Notifications
You must be signed in to change notification settings - Fork 25.1k
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
Remove timezone validation on rollup range queries #40647
Remove timezone validation on rollup range queries #40647
Conversation
We enforced the timezone of range queries when using the rollup search endpoint, but this validation is not needed. Since rollup dates are stored in UTC, and range queries are always converted to UTC (even if specifying a `time_zone`) the validation is not needed and can prevent legitimate queries from running.
Pinging @elastic/es-analytics-geo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@elasticmachine run elasticsearch-ci/2 |
@elasticmachine test this please |
Note that we have a blocker on Kibana caused by this: elastic/kibana#33974 |
@rayafratkina When I discussed with @jasontedor earlier we decided it didn't qualify as a blocker for the 7.0 train because Rollup is still an experimental feature, and this only impacts dashboards that are using non-UTC timezones. Also, this validation has been there since 6.4 so I'm surprised dashboards are/were working at all with non-UTC timezones (from the timepicker range, not the date_histo config). |
We enforced the timezone of range queries when using the rollup search endpoint, but this validation is not needed. Since rollup dates are stored in UTC, and range queries are always converted to UTC (even if specifying a `time_zone`) the validation is not needed and can prevent legitimate queries from running.
We enforced the timezone of range queries when using the rollup search endpoint, but this validation is not needed. Since rollup dates are stored in UTC, and range queries are always converted to UTC (even if specifying a `time_zone`) the validation is not needed and can prevent legitimate queries from running.
* master: add reason to DataFrameTransformState and add hlrc protocol tests (elastic#40736) Remove timezone validation on rollup range queries (elastic#40647) Fix testRunStateChangePolicyWithAsyncActionNextStep race condition (elastic#40707) Don't mark shard as refreshPending on stats fetching (elastic#40458) Name Snapshot Data Blobs by UUID (elastic#40652) SQL: [TEST] Mute TIME related failing tests [TEST] RecoveryWithConcurrentIndexing test (elastic#40733)
@polyfractal this looks like its still pending the backport for 6.7, is that correct? I'm going to label it assuming this is correct for now |
Sorry yes, still waiting on backport to 6.7 |
We enforced the timezone of range queries when using the rollup search endpoint, but this validation is not needed. Since rollup dates are stored in UTC, and range queries are always converted to UTC (even if specifying a `time_zone`) the validation is not needed and can prevent legitimate queries from running.
We enforced the timezone of range queries when using the rollup search endpoint, but this validation is not needed. Since rollup dates are stored in UTC, and range queries are always converted to UTC (even if specifying a `time_zone`) the validation is not needed and can prevent legitimate queries from running.
Hello, |
We enforced the timezone of range queries when using the rollup search endpoint, but this validation is not needed. Since rollup dates are stored in UTC, and range queries are always converted to UTC (even if specifying a
time_zone
) the validation is not needed and can prevent legitimate queries from running.