@@ -70,7 +70,6 @@ POST /sales/_search?size=0
7070 }
7171}
7272```
73-
7473% TEST[ setup: sales ]
7574
7675If you attempt to use multiples of calendar units, the aggregation will fail because only singular calendar units are supported:
@@ -90,9 +89,7 @@ POST /sales/_search?size=0
9089 }
9190}
9291```
93-
9492% TEST[ setup: sales ]
95-
9693% TEST[ catch: bad_request ]
9794
9895``` js
@@ -109,7 +106,6 @@ POST /sales/_search?size=0
109106 }
110107}
111108```
112-
113109% NOTCONSOLE
114110
115111
@@ -158,7 +154,6 @@ POST /sales/_search?size=0
158154 }
159155}
160156```
161-
162157% TEST[ setup: sales ]
163158
164159But if we try to use a calendar unit that is not supported, such as weeks, we’ll get an exception:
@@ -178,9 +173,7 @@ POST /sales/_search?size=0
178173 }
179174}
180175```
181-
182176% TEST[ setup: sales ]
183-
184177% TEST[ catch: bad_request ]
185178
186179``` js
@@ -197,7 +190,6 @@ POST /sales/_search?size=0
197190 }
198191}
199192```
200-
201193% NOTCONSOLE
202194
203195
@@ -251,7 +243,6 @@ POST /sales/_search?size=0
251243 }
252244}
253245```
254-
255246% TEST[ setup: sales ]
256247
2572481 . Supports expressive date [ format pattern] ( /reference/data-analysis/aggregations/search-aggregations-bucket-daterange-aggregation.md#date-format-pattern )
@@ -285,7 +276,6 @@ Response:
285276 }
286277}
287278```
288-
289279% TESTRESPONSE[ s/\.\.\. /"took": $body.took,"timed_out": false,"_ shards": $body._ shards,"hits": $body.hits,/]
290280
291281
@@ -355,7 +345,6 @@ If you don’t specify a time zone, UTC is used. This would result in both of th
355345 }
356346}
357347```
358-
359348% TESTRESPONSE[ s/\.\.\. /"took": $body.took,"timed_out": false,"_ shards": $body._ shards,"hits": $body.hits,/]
360349
361350If you specify a ` time_zone ` of ` -01:00 ` , midnight in that time zone is one hour before midnight UTC:
@@ -374,7 +363,6 @@ GET my-index-000001/_search?size=0
374363 }
375364}
376365```
377-
378366% TEST[ continued]
379367
380368Now the first document falls into the bucket for 30 September 2015, while the second document falls into the bucket for 1 October 2015:
@@ -400,7 +388,6 @@ Now the first document falls into the bucket for 30 September 2015, while the se
400388 }
401389}
402390```
403-
404391% TESTRESPONSE[ s/\.\.\. /"took": $body.took,"timed_out": false,"_ shards": $body._ shards,"hits": $body.hits,/]
405392
4063931 . The ` key_as_string ` value represents midnight on each day in the specified time zone.
@@ -468,7 +455,6 @@ Instead of a single bucket starting at midnight, the above request groups the do
468455 }
469456}
470457```
471-
472458% TESTRESPONSE[ s/\.\.\. /"took": $body.took,"timed_out": false,"_ shards": $body._ shards,"hits": $body.hits,/]
473459
474460::::{note}
@@ -498,7 +484,6 @@ $$$datehistogram-aggregation-offset-example-19d$$$
498484 { "key_as_string": "2022-08-20", "key": 1660953600000, "doc_count": 1 }
499485]
500486```
501-
502487% TESTRESPONSE[ skip: no setup made for this example yet]
503488
504489Increasing the offset to ` +20d ` , each document will appear in a bucket for the previous month, with all bucket keys ending with the same day of the month, as normal. However, further increasing to ` +28d ` , what used to be a February bucket has now become ` "2022-03-01" ` .
@@ -517,7 +502,6 @@ $$$datehistogram-aggregation-offset-example-28d$$$
517502 { "key_as_string": "2022-07-29", "key": 1659052800000, "doc_count": 1 }
518503]
519504```
520-
521505% TESTRESPONSE[ skip: no setup made for this example yet]
522506
523507If we continue to increase the offset, the 30-day months will also shift into the next month, so that 3 of the 8 buckets have different days than the other five. In fact if we keep going, we will find cases where two documents appear in the same month. Documents that were originally 30 days apart can be shifted into the same 31-day month bucket.
@@ -535,7 +519,6 @@ $$$datehistogram-aggregation-offset-example-50d$$$
535519 { "key_as_string": "2022-08-20", "key": 1660953600000, "doc_count": 1 }
536520]
537521```
538-
539522% TESTRESPONSE[ skip: no setup made for this example yet]
540523
541524It is therefore always important when using ` offset ` with ` calendar_interval ` bucket sizes to understand the consequences of using offsets larger than the interval size.
@@ -568,7 +551,6 @@ POST /sales/_search?size=0
568551 }
569552}
570553```
571-
572554% TEST[ setup: sales ]
573555
574556Response:
@@ -599,7 +581,6 @@ Response:
599581 }
600582}
601583```
602-
603584% TESTRESPONSE[ s/\.\.\. /"took": $body.took,"timed_out": false,"_ shards": $body._ shards,"hits": $body.hits,/]
604585
605586
@@ -634,7 +615,6 @@ POST /sales/_search?size=0
634615 }
635616}
636617```
637-
638618% TEST[ setup: sales ]
639619
640620%
@@ -693,7 +673,6 @@ POST /sales/_search?size=0
693673 }
694674}
695675```
696-
697676% TEST[ setup: sales ]
698677
6996781 . Documents without a value in the ` date ` field will fall into the same bucket as documents that have the value ` 2000-01-01 ` .
@@ -727,7 +706,6 @@ POST /sales/_search?size=0
727706 }
728707}
729708```
730-
731709% TEST[ setup: sales ]
732710
733711Response:
@@ -753,7 +731,6 @@ Response:
753731 }
754732}
755733```
756-
757734% TESTRESPONSE[ s/\.\.\. /"took": $body.took,"timed_out": false,"_ shards": $body._ shards,"hits": $body.hits,/]
758735
759736The response will contain all the buckets having the relative day of the week as key : 1 for Monday, 2 for Tuesday… 7 for Sunday.
0 commit comments