@@ -56,7 +56,7 @@ will be removed in the future.
56
56
==================================
57
57
58
58
[[calendar_intervals]]
59
- ===== Calendar intervals
59
+ ==== Calendar intervals
60
60
61
61
Calendar-aware intervals are configured with the `calendar_interval` parameter.
62
62
You can specify calendar intervals using the unit name, such as `month`, or as a
@@ -173,7 +173,7 @@ POST /sales/_search?size=0
173
173
// NOTCONSOLE
174
174
175
175
[[fixed_intervals]]
176
- ===== Fixed intervals
176
+ ==== Fixed intervals
177
177
178
178
Fixed intervals are configured with the `fixed_interval` parameter.
179
179
@@ -267,7 +267,7 @@ POST /sales/_search?size=0
267
267
// NOTCONSOLE
268
268
269
269
[[datehistogram-aggregation-notes]]
270
- ===== Notes
270
+ ==== Date histogram usage notes
271
271
272
272
In all cases, when the specified end time does not exist, the actual end time is
273
273
the closest available time after the specified end.
@@ -282,17 +282,17 @@ As always, rigorous testing, especially around time-change events, will ensure
282
282
that your time interval specification is
283
283
what you intend it to be.
284
284
285
- WARNING:
286
- To avoid unexpected results, all connected servers and clients must sync to a
287
- reliable network time service.
285
+ WARNING: To avoid unexpected results, all connected servers and clients must
286
+ sync to a reliable network time service.
288
287
289
- NOTE: fractional time values are not supported, but you can address this by
288
+ NOTE: Fractional time values are not supported, but you can address this by
290
289
shifting to another time unit (e.g., `1.5h` could instead be specified as `90m`).
291
290
292
291
NOTE: You can also specify time values using abbreviations supported by
293
292
<<time-units,time units>> parsing.
294
293
295
- ===== Keys
294
+ [[datehistogram-aggregation-keys]]
295
+ ==== Keys
296
296
297
297
Internally, a date is represented as a 64 bit number representing a timestamp
298
298
in milliseconds-since-the-epoch (01/01/1970 midnight UTC). These timestamps are
@@ -353,7 +353,8 @@ Response:
353
353
--------------------------------------------------
354
354
// TESTRESPONSE[s/\.\.\./"took": $body.took,"timed_out": false,"_shards": $body._shards,"hits": $body.hits,/]
355
355
356
- ===== Time zone
356
+ [[datehistogram-aggregation-time-zone]]
357
+ ==== Time zone
357
358
358
359
{es} stores date-times in Coordinated Universal Time (UTC). By default, all bucketing and
359
360
rounding is also done in UTC. Use the `time_zone` parameter to indicate
@@ -489,7 +490,7 @@ shorter intervals, like a `fixed_interval` of `12h`, where you'll have only a 11
489
490
bucket on the morning of 27 March when the DST shift happens.
490
491
491
492
[[search-aggregations-bucket-datehistogram-offset]]
492
- ===== Offset
493
+ ==== Offset
493
494
494
495
// tag::offset-explanation[]
495
496
Use the `offset` parameter to change the start value of each bucket by the
@@ -562,7 +563,8 @@ NOTE: The start `offset` of each bucket is calculated after `time_zone`
562
563
adjustments have been made.
563
564
// end::offset-note[]
564
565
565
- ===== Keyed Response
566
+ [[date-histogram-keyed-response]]
567
+ ==== Keyed Response
566
568
567
569
Setting the `keyed` flag to `true` associates a unique string key with each
568
570
bucket and returns the ranges as a hash rather than an array:
@@ -616,7 +618,8 @@ Response:
616
618
--------------------------------------------------
617
619
// TESTRESPONSE[s/\.\.\./"took": $body.took,"timed_out": false,"_shards": $body._shards,"hits": $body.hits,/]
618
620
619
- ===== Scripts
621
+ [[date-histogram-scripts]]
622
+ ==== Scripts
620
623
621
624
As with the normal <<search-aggregations-bucket-histogram-aggregation,histogram>>,
622
625
both document-level scripts and
@@ -632,6 +635,7 @@ For more information, see
632
635
<<search-aggregations-bucket-histogram-aggregation-extended-bounds,`Extended Bounds`>> and
633
636
<<search-aggregations-bucket-histogram-aggregation-hard-bounds,`Hard Bounds`>>.
634
637
638
+ [[date-histogram-missing-value]]
635
639
===== Missing value
636
640
637
641
The `missing` parameter defines how to treat documents that are missing a value.
@@ -658,19 +662,20 @@ POST /sales/_search?size=0
658
662
<1> Documents without a value in the `publish_date` field will fall into the
659
663
same bucket as documents that have the value `2000-01-01`.
660
664
665
+ [[date-histogram-order]]
661
666
===== Order
662
667
663
668
By default the returned buckets are sorted by their `key` ascending, but you can
664
669
control the order using
665
670
the `order` setting. This setting supports the same `order` functionality as
666
671
<<search-aggregations-bucket-terms-aggregation-order,`Terms Aggregation`>>.
667
672
673
+ [[date-histogram-aggregate-scripts]]
668
674
===== Using a script to aggregate by day of the week
669
675
670
676
When you need to aggregate the results by day of the week, use a script that
671
677
returns the day of the week:
672
678
673
-
674
679
[source,console,id=datehistogram-aggregation-script-example]
675
680
--------------------------------------------------
676
681
POST /sales/_search?size=0
0 commit comments