导航
导航

es时间相差8小时问题

2018.10.01 sherryriver 流水账技术  pv:

各位在实际生产中使用es应该会遇到查询日期时8小时误差问题

es储存的时间 2018-05-22T04:34:21.000Z
mysql存入的时间 2018-05-22 12:34:21

原因是由于es默认日期时UTC时间。

几个时间名词：

（1）GMT:格林威治标准时间

（2）UTC:世界协调时间

（3）DST:夏日节约时间

（4）CST:中国标准时间

其中GMT时间可以近似认为和UTC时间是相等的，但从精度上来说UTC时间更精确。其误差值必须保持在0.9秒以内

CST= GMT + 8 =UTC + 8

从上面可以看出来中国的时间是等于UTC时间+8小时

说下目前公司的解决方案：
刚项目时候，我司老同事就已经帮我们填这个小坑，在返回数据的字段属性上标注，基于jackson的转化

@JsonFormat(with = JsonFormat.Feature.ADJUST_DATES_TO_CONTEXT_TIME_ZONE)

自我感觉，后期开发中疏忽会漏掉注解，而且mysql与es对于相同的数据返回，由于es的缘故就得定义不同的DTO。
遂想找更合理的解决方法，最优的方案当然就是改数据源啦
又“研究”起了架构师封装的es接口

部分代码如下：


public ElasticSearchRepository() {
       objectMapper = new ObjectMapper()
               .disable(DeserializationFeature.FAIL_ON_IGNORED_PROPERTIES, DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES)
               .enable(JsonGenerator.Feature.IGNORE_UNKNOWN)
               .setPropertyNamingStrategy(PropertyNamingStrategy.SNAKE_CASE);
       /*format = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'");
       format.setTimeZone(TimeZone.getTimeZone("UTC"));*/

       format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
       format.setTimeZone(TimeZone.getTimeZone("GMT+8")); // 替换为Asia/Shanghai也是可以的

       objectMapper.setDateFormat(format);
   }

改造前，仍是使用UTC时间
改造后直接转为通用格式yyyy-MM-dd HH:mm:ss的话，时间是少8小时的，将时区设为为北京时区