在ElasticSearch里面最常用的就是时间字段了，经常会在群里看到一些小伙伴提出有关时间的问题，为什么es查询的时间跟我实际看到的时间差8个小时呢。如果我们了解了ElasticSearch底层的时间存储方式就会比较容易的理解这个问题。
下面散仙先普及下时区的知识，想必大家也不陌生学过地理的同学都知道全球有24个时区每个时区的跨度是经度15度，
相较于两地时间表，可以显示世界各时区时间和地名的世界时区表（World Time），就显得精密与复杂多了，通常世界时区表的表盘上会标示着全球24个时区的城市名称，但究竟这24个时区是如何产生的？过去世界各地原本各自订定当地时间，但随着交通和电讯的发达，各地交流日益频繁，不同的地方时间，造成许多困扰，于是在西元1884年的国际会议上制定了全球性的标准时，明定以英国伦敦格林威治这个地方为零度经线的起点（亦称为本初子午线），并以地球由西向东每24小时自转一周360°，订定每隔经度15°，时差1小时。而每15°的经线则称为该时区的中央经线，将全球划分为24个时区，其中包含23个整时区及180°经线左右两侧的2个半时区 就全球的时间来看，东经的时间比西经要早，也就是如果格林威治时间是中午12时，则中央经线15°E的时区为下午1时，中央经线30°E时区的时间为下午2时；反之，中央经线15°W的时区时间为上午11时，中央经线30°W时区的时间为上午10时。以中国台湾为例，中国台湾位于东经121°，换算后与格林威治就有8小时的时差。如果两人同时从格林威治的0°各往东、西方前进，当他们在经线180°时，就会相差24小时，所以经线180°被定为国际换日线，由西向东通过此线时日期要减去一日，反之，若由东向西则要增加一日。
几个时间名词：
（1）GMT:格林威治标准时间
（2）UTC:世界协调时间
（3）DST:夏日节约时间
（4）CST:中国标准时间
其中GMT时间可以近似认为和UTC时间是相等的，但从精度上来说UTC时间更精确。其误差值必须保持在0.9秒以内
CST= GMT 8 =UTC 8
从上面可以看出来中国的时间是等于UTC时间 8小时，es默认存储时间的格式是UTC时间，如果我们查询es然后获取时间日期默认的数据，会发现跟当前的时间差8个小时，这其实是正常的，因为es默认存储是用的UTC时间，所以我们需要做的就是读取long型时间戳，然后重新格式化成下面的时间戳，即可获得正确的时间
代码语言：javascript复制
yyyy-MM-dd HH:mm:ss
像差8个时区的事情，最容易见到的就是，我们使用logstash收集的日志，发送到es里面，然后通过head查询就能发现不一致，但是如果我们用kibana查询，就不会发现时区问题，为什么？ 因为kibana已经处理时区问题了，所以在kibana的页面显示的时间是正确的。
此外在使用Java Client聚合查询日期的时候，需要注意时区问题，因为默认的es是按照UTC标准时区算的，所以不设置的聚合统计结果是不正确的。
在es的DateHistogramBuilder里面有几个比较重要的参数：
注意，默认不设置时区参数，es是安装UTC的时间进行查询的，所以分组的结果可能与预期不一样，所以我们要指定时区为Asia/Shanghai代表北京的时区，这样才能获取正确的聚合结果
curl方式如下：
Java代码如下：
上面的这个例子，基本涵盖了日期聚合核心功能，其中时区和偏移量时两个非常有用的而且需要特别注意的参数，不设置时区直接统计结果肯定是不准确的，offset偏移量这个参数，在某些时刻也是有用的，它可以自己定义一天的开始，比如设置从第一天的3点到第二天的3点为一天，默认都是从0点开始0点结束算做一天的，最后一点需要注意的是在输出打印时间的时候也要考虑转化因为默认也是UTC的时间，所以我们直接取出时间戳，自己格式化时间即可。
官网文档：
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-datehistogram-aggregation.html
