-
Notifications
You must be signed in to change notification settings - Fork 24.3k
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
Inconsistent behavior/documentation with Date Agg Intervals #50091
Comments
Pinging @elastic/es-analytics-geo (:Analytics/Aggregations) |
Heya, thanks for the detailed ticket... and apologies for the confusion/troubles :( I'll start with the easy ones first: Kibana
Correct, although hopefully only temporarily. Kibana, like many user applications, is still migrating off the old Nanoseconds
Nanoseconds are in a tricky situation right now. They can be indexed and searched (at cost of reduced dynamic range), but aggregations currently only work in millisecond range regardless of the underlying data type. This is noted in the date_nano docs at the bottom. That's why nano support isn't mentioned on the date histogram page. DateHistogramInterval helpers
These are technically just "helper" methods, and were more useful with the old
Intervals
This should work for
This should work for
This should not work, and I don't think it's ever been supported. E.g. neither of the calendar-aware parsers in 6.0 or 2.0 support just the unit by itself, and fixed intervals don't support calendar concepts like months. I just tested on a 6.0 build and it does indeed throw an exception:
I tested the fixed units too and they also don't work, although from a parsing issue and an ugly exception:
ConclusionsSo in conclusion it seems we (ES) has two action items:
I hope this helped clear up the situation! |
Pinging @elastic/es-docs (Team:Docs) |
Elasticsearch version (
bin/elasticsearch --version
): 7.5Plugins installed: ["mapper-size"]
JVM version (
java -version
): docker-imageOS version (
uname -a
if on a Unix-like system): docker-imageDescription of the problem including expected versus actual behavior:
We noticed that aggregations don't behave how we expected them to as per the docs. Please see this issue we logged on nest for more context: elastic/elasticsearch-net#4251
Steps to reproduce:
The docs state that
1M
,month
andM
are valid calendar intervals. However not all of them work correctly when running in ES. This translates to pretty much all the values listed in the documentation (on two different pages, one talks about nanos and micro seconds but the main documentation doesn't)Also of note, it appears when you use kibana it creates a date_histogram via a snippet using interval (legacy).
Provide logs (if relevant):
I doing a
date_histogram
aggregation withcalendar_interval
values of:1M
1M
toDateHistogramAggregationDescriptor<T>.CalendarInterval
month
month
toDateHistogramAggregationDescriptor<T>.CalendarInterval
withExpression 'month' is invalid
M
The supplied interval [M] could not be parsed as a calendar interval.
, but the documentation page says that it is a valid value.M
toDateHistogramAggregationDescriptor<T>.CalendarInterval
withExpression 'M' is invalid
Originally posted by @ejsmith in elastic/elasticsearch-net#4251 (comment)
The Date Histogram docs have fixed intervals to milliseconds. The time values docs have values down to nanos.
I'm not sure what the smallest value supported for buckets is, but looking at
DateHistogramInterval
, it looks like it may be1s
, which can also be supplied as1000ms
input:elasticsearch/server/src/main/java/org/elasticsearch/search/aggregations/bucket/histogram/DateHistogramInterval.java
Lines 37 to 66 in 6ae6f57
There's something not right; either the documentation should be clearer, or the implementation should also support the single character time units, which it looks like it doesn't
elasticsearch/server/src/main/java/org/elasticsearch/search/aggregations/bucket/histogram/DateHistogramAggregationBuilder.java
Lines 79 to 98 in 23bf310
Originally posted by @russcam in elastic/elasticsearch-net#4251 (comment)
The text was updated successfully, but these errors were encountered: