-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Date field mapping "epoch_millis" errors on date aggregations with timezones other than UTC #31392
Labels
>bug
:Search Foundations/Mapping
Index mappings, including merging and defining field types
Team:Search Foundations
Meta label for the Search Foundations team in Elasticsearch
v6.4.0
v7.0.0-beta1
Comments
cbuescher
added
>bug
:Search Foundations/Mapping
Index mappings, including merging and defining field types
v7.0.0
v6.4.0
labels
Jun 18, 2018
Pinging @elastic/es-search-aggs |
Specifying
Throws
|
I might have a fix, still working on tests though before opening a PR. |
cbuescher
pushed a commit
to cbuescher/elasticsearch
that referenced
this issue
Jun 18, 2018
Currently, DateHistogramAggregationBuilder#rewriteTimeZone uses the aggregation date math parser and time zone to check whether all values in a read have the same timezone to speed up computation. However, the upper and lower bounds to check are retrieved as longs in epoch_millis, so they don't need to get parsed using a time zone or a parser other than "epoch_millis". This changes this behaviour that was causing problems when the field type mapping was specifying only "epoch_millis" as a format but a different timezone than UTC was used. Closes elastic#31392
cbuescher
pushed a commit
that referenced
this issue
Jun 20, 2018
Currently, DateHistogramAggregationBuilder#rewriteTimeZone uses the aggregation date math parser and time zone to check whether all values in a read have the same timezone to speed up computation. However, the upper and lower bounds to check are retrieved as longs in epoch_millis, so they don't need to get parsed using a time zone or a parser other than "epoch_millis". This changes this behaviour that was causing problems when the field type mapping was specifying only "epoch_millis" as a format but a different timezone than UTC was used. Closes #31392
cbuescher
pushed a commit
that referenced
this issue
Jun 20, 2018
Currently, DateHistogramAggregationBuilder#rewriteTimeZone uses the aggregation date math parser and time zone to check whether all values in a read have the same timezone to speed up computation. However, the upper and lower bounds to check are retrieved as longs in epoch_millis, so they don't need to get parsed using a time zone or a parser other than "epoch_millis". This changes this behaviour that was causing problems when the field type mapping was specifying only "epoch_millis" as a format but a different timezone than UTC was used. Closes #31392
javanna
added
the
Team:Search Foundations
Meta label for the Search Foundations team in Elasticsearch
label
Jul 16, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
>bug
:Search Foundations/Mapping
Index mappings, including merging and defining field types
Team:Search Foundations
Meta label for the Search Foundations team in Elasticsearch
v6.4.0
v7.0.0-beta1
As demonstrated in elastic/kibana#19858, having a date field with
"format": "epoch_millis"
can causeerrors when running date histogram aggregations with a time zone other than UTC. I think this problem was introduced as a side effect of #30534. While throwing an error for parsing time values with
"format": "epoch_millis"
and timezones other than UTC looks like the intented behaviour (see #22621), it should be able to overwrite this by specifyingformat
in the aggregation. This however doesn't seem to work currently on 6.x.The text was updated successfully, but these errors were encountered: