# Handling 1d date\_histogram queries that span Daylight Saving Time (Nov 6th 2 am)

**URL:** <https://discuss.elastic.co/t/handling-1d-date-histogram-queries-that-span-daylight-saving-time-nov-6th-2-am/69623>\
**Category:** Elasticsearch\
**Created:** [December 20, 2016, 10:58pm UTC](https://discuss.elastic.co/t/handling-1d-date-histogram-queries-that-span-daylight-saving-time-nov-6th-2-am/69623 "2016-12-20T22:58:51Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![yeppers](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/yeppers/32/8078_2.png) [@yeppers](https://discuss.elastic.co/u/yeppers)\
**Post date:** [December 20, 2016, 10:58pm UTC](https://discuss.elastic.co/t/handling-1d-date-histogram-queries-that-span-daylight-saving-time-nov-6th-2-am/69623/1 "2016-12-20T22:58:51Z")

</div>

I store all my documents with date/times in GMT. Then at query time I use the "time\_zone" property of a date\_histogram to choose which timezone to localize it to (we have users in multiple time zones).

This works great; however, I have ran into a problem for queries that span the daylight saving time change on Nov 6th and use 1d intervals. The problem arises because on Nov 6 at 2am the timezone offset changes e.g. on Nov 6th at 1 am the US Central timezone is GMT-0500, at Nov 6th at 2am the US Central timezone is GMT-0600. Since you can only choose one time\_zone for the query everything past Nov 6th is one hour off i.e. days appear to start at 11 pm the previous day. And a 30 day Nov 1-Nov 30 query using 1d intervals gets 31 buckets, where the 31st bucket is the first hour of Dec 1st.

In reality Nov 1st - Nov 6th at 2am should be queried with time\_zone offset -0500 and after Nov 6th at 2 am the time\_zone offset should change to -0600.

How have other people handled this?

---

<div class="post-metadata">

**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\
**Post date:** [December 27, 2016, 6:54am UTC](https://discuss.elastic.co/t/handling-1d-date-histogram-queries-that-span-daylight-saving-time-nov-6th-2-am/69623/2 "2016-12-27T06:54:11Z")

</div>

ES doesn't care about this, it leaves it to the client. So doing that yourself is cleanest and best 🙂

---

<div class="post-metadata">

**Author:** ![yeppers](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/yeppers/32/8078_2.png) [@yeppers](https://discuss.elastic.co/u/yeppers)\
**Post date:** [December 27, 2016, 3:30pm UTC](https://discuss.elastic.co/t/handling-1d-date-histogram-queries-that-span-daylight-saving-time-nov-6th-2-am/69623/3 "2016-12-27T15:30:56Z")

</div>

Actually your response isn't true at all. If you use a raw offset (e.g -0500) in the "time\_zone" parameter (or "pre\_zone" in earlier versions of ES) then no daylight saving time is taken into account. However, if you use a timezone ID that supports daylight saving time (e.g. "US/Central") then ES does indeed take into account time changes if they occur during the span of your query.

(got my answer by opening a support request to Elastic).

---

<div class="post-metadata">

**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\
**Post date:** [December 27, 2016, 7:26pm UTC](https://discuss.elastic.co/t/handling-1d-date-histogram-queries-that-span-daylight-saving-time-nov-6th-2-am/69623/4 "2016-12-27T19:26:27Z")

</div>

Oh, there you go! 😃

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [January 24, 2017, 7:26pm UTC](https://discuss.elastic.co/t/handling-1d-date-histogram-queries-that-span-daylight-saving-time-nov-6th-2-am/69623/5 "2017-01-24T19:26:39Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
