Edited 300_Aggregations/35_date_histogram.asciidoc with Atlas code editor

Author: skalapurakkel

300_Aggregations/35_date_histogram.asciidoc

@@ -1,43 +1,41 @@
 
-== Looking at time
+== Looking at Time
 
 If search is the most popular activity in Elasticsearch, building date
 histograms must be the second most popular.((("date histograms, building")))((("histograms", "building date histograms")))((("aggregations", "building date histograms from")))  Why would you want to use a date
 histogram?
 
-Imagine your data has a timestamp.((("time, analytics over", id="ix_timeanalyze")))  It doesn't matter what the data is -- Apache
-log events, stock buy/sell transaction dates, baseball game times
--- anything with a timestamp can benefit from the date histogram.  When you have
-a timestamp, you often want to build metrics which are expressed _over time_.
+Imagine your data has a timestamp.((("time, analytics over", id="ix_timeanalyze")))  It doesn't matter what the data is--Apache
+log events, stock buy/sell transaction dates, baseball game times--anything with a timestamp can benefit from the date histogram.  When you have
+a timestamp, you often want to build metrics that are expressed _over time_:
 
 - How many cars sold each month this year?
 - What was the price of this stock for the last 12 hours?
 - What was the average latency of our website every hour in the last week?
 
 While regular histograms are often represented as bar charts, date histograms
 tend to be converted into line graphs representing time series.((("analytics", "over time")))  Many
-companies use Elasticsearch _solely_ for analytics over time-
-series data.  The `date_histogram` bucket is their bread and butter.
+companies use Elasticsearch _solely_ for analytics over time series data.  The `date_histogram` bucket is their bread and butter.
 
-The `date_histogram` bucket works((("buckets", "date_histogram"))) very similar to the regular `histogram`.  Rather
+The `date_histogram` bucket works((("buckets", "date_histogram"))) similarly to the regular `histogram`.  Rather
 than building buckets based on a numeric field representing numeric ranges,
-it builds buckets based on a time ranges.  Each bucket is therefore defined as a
-certain calendar size (e.g. `1 month` or `2.5 days`, etc).
+it builds buckets based on time ranges.  Each bucket is therefore defined as a
+certain calendar size (for example, `1 month` or `2.5 days`).
 
-.Can a regular histogram work with dates?
+.Can a Regular Histogram Work with Dates?
 ****
 Technically, yes.((("histogram bucket", "dates and")))  A regular `histogram` bucket will work with dates.  However,
 it is not calendar-aware.  With the `date_histogram`, you can specify intervals
 such as `1 month`, which knows that February is shorter than December.  The
-`date_histogram` also has the advantage of being able to work with timezones,
-which allows you to customize graphs to the timezone of the user, not the server.
+`date_histogram` also has the advantage of being able to work with time zones,
+which allows you to customize graphs to the time zone of the user, not the server.
 
 The regular histogram will interpret dates as numbers, which means you must specify
 intervals in terms of milliseconds.  And the aggregation doesn't know about
 calendar intervals, which makes it largely useless for dates.
 ****
 
-Our first example ((("line charts, building from aggregations")))will build a simple line chart to answer the question:
+Our first example ((("line charts, building from aggregations")))will build a simple line chart to answer this question:
 how many cars were sold each month?
 
 [source,js]
@@ -56,13 +54,13 @@ GET /cars/transactions/_search?search_type=count
 }
 --------------------------------------------------
 // SENSE: 300_Aggregations/35_date_histogram.json
-<1> The interval is requested in calendar terminology (e.g. one month per bucket)
+<1> The interval is requested in calendar terminology (for example, one month per bucket).
 // "pretty"-> "readable by humans". mention that otherwise get back ms-since-epoch?
-<2> We provide a date format so that bucket keys are pretty
+<2> We provide a date format so that bucket keys are pretty.
 
 Our query has a single aggregation, which builds a bucket
 per month.  This will give us the number of cars sold in each month.  An additional
-"format" parameter is provided so that the buckets have "pretty" keys.  Internally,
+format" parameter is provided so that the buckets have "pretty" keys.  Internally,
 dates are simply represented as a numeric value.  This tends to make UI designers
 grumpy, however, so a prettier format can be specified using common date formatting.