怎么排查因JDK導致接口輸出日期格式的時間與預期時間不一致問題

本篇內容主要講解“怎么排查因JDK導致接口輸出日期格式的時間與預期時間不一致問題”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“怎么排查因JDK導致接口輸出日期格式的時間與預期時間不一致問題”吧!

bug描述

問題起源于同事在項目中新增一個統計用戶生日明細的接口，其中一個用戶在數據庫中的生日日期是“1988-07-29”,然而通過rest接口得到該用戶的生日日期卻為 “1988-07-28”。

環境說明

開始bug排查之前，先說明下項目環境：

• 系統：centos 7.5

• JDK：1.8.0_171

• 技術棧：spring boot、Jackson、Druid、mybatis、oracle。

bug 排查

從數據層開始查找，先查詢數據庫時間和時區。

SQL> SELECT SYSTIMESTAMP, SESSIONTIMEZONE FROM DUAL;
SYSTIMESTAMP                                                                     SESSIONTIMEZONE
-------------------------------------------------------------------------------- ---------------------------------------------------------------------------
17-JUL-19 02.20.06.687149 PM +08:00                                              +08:00

SQL>

數據庫時間和時區都沒有問題。

確認操作系統和java進程時區

• 查看操作系統時區

[test@test ~]$ date -R
Wed, 17 Jul 2019 16:48:32 +0800
[test@test ~]$ cat /etc/timezone
Asia/Shanghai

• 查看java進程時區

[test@test ~]$ jinfo 7490 |grep user.timezone
user.timezone = Asia/Shanghai

可以看出我們操作系統使用的時區和java進程使用的時區一致，都是東八區。

用debug繼續往上層查找查看mybatis和JDBC層

查看了問題字段mapper映射字段的jdbcType類型為jdbcType="TIMESTAMP"，在mybatis中類型處理注冊類TypeHandlerRegistry.java 中對應的處理類為 DateTypeHandler.java。

this.register((JdbcType)JdbcType.TIMESTAMP, (TypeHandler)(new DateTypeHandler()));

進一步查看 DateTypeHandler.java 類：

//
// Source code recreated from a .class file by IntelliJ IDEA
// (powered by Fernflower decompiler)
//

package org.apache.ibatis.type;

import java.sql.CallableStatement;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Timestamp;
import java.util.Date;

public class DateTypeHandler extends BaseTypeHandler<Date> {
  public DateTypeHandler() {
  }

  public void setNonNullParameter(PreparedStatement ps, int i, Date parameter, JdbcType jdbcType) throws SQLException {
    ps.setTimestamp(i, new Timestamp(parameter.getTime()));
  }

  public Date getNullableResult(ResultSet rs, String columnName) throws SQLException {
    Timestamp sqlTimestamp = rs.getTimestamp(columnName);
    return sqlTimestamp != null ? new Date(sqlTimestamp.getTime()) : null;
  }

  public Date getNullableResult(ResultSet rs, int columnIndex) throws SQLException {
    Timestamp sqlTimestamp = rs.getTimestamp(columnIndex);
    return sqlTimestamp != null ? new Date(sqlTimestamp.getTime()) : null;
  }

  public Date getNullableResult(CallableStatement cs, int columnIndex) throws SQLException {
    Timestamp sqlTimestamp = cs.getTimestamp(columnIndex);
    return sqlTimestamp != null ? new Date(sqlTimestamp.getTime()) : null;
  }
}

因為使用的數據源為Druid，其中 getNullableResult(ResultSet rs, String columnName) 方法參數中 ResultSet使用了DruidPooledResultSet.java 的 getTimestamp(String columnLabel) ，通過列名稱獲取值然后轉換為Date類型的值。

由上圖debug看到 Timestamp 是JDK中的類，也就是說這里看到的是JDK使用的時間和時區，從圖中標注2處可以看出JDK使用的時區也是東八區，但是從1和3處看起來似乎有點不一樣，首先1處變化為UTC/GMT+0900，3處有一個daylightSaving的這樣一個時間，換算為小時剛好為1個小時。這個值通過google搜索知道叫做夏令時。

常用時間概念 UTC，GMT，CST，DST

• UTC 協調世界時（英語：Coordinated Universal Time，法語：Temps Universel Coordonné，簡稱UTC）是最主要的世界時間標準，其以原子時秒長為基礎，在時刻上盡量接近于格林尼治標準時間。中華民國采用CNS 7648的《資料元及交換格式–資訊交換–日期及時間的表示法》（與ISO 8601類似）稱之為世界協調時間。中華人民共和國采用ISO 8601:2000的國家標準GB/T 7408-2005《數據元和交換格式 信息交換 日期和時間表示法》中亦稱之為協調世界時。（摘自：https://zh.wikipedia.org/wiki/%E5%8D%8F%E8%B0%83%E4%B8%96%E7%95%8C%E6%97%B6）

• GMT 格林尼治標準時間（英語：Greenwich Mean Time，GMT）是指位于英國倫敦郊區的皇家格林尼治天文臺當地的平太陽時，因為本初子午線被定義為通過那里的經線。（摘自：https://zh.wikipedia.org/wiki/%E6%A0%BC%E6%9E%97%E5%B0%BC%E6%B2%BB%E6%A8%99%E6%BA%96%E6%99%82%E9%96%93）

• CST 北京時間，又名中國標準時間，是中國大陸的標準時間，比世界協調時快八小時（即UTC+8），與香港、澳門、臺北、吉隆坡、新加坡等地的標準時間相同。

  北京時間并不是北京市的地方平太陽時間（東經116.4°），而是東經120°的地方平太陽時間，二者相差約14.5分鐘[1]。北京時間由位于中國版圖幾何中心位置陜西臨潼的中國科學院國家授時中心的9臺銫原子鐘和2臺氫原子鐘組通過精密比對和計算實現報時，并通過人造衛星與世界各國授時部門進行實時比對。（摘自：https://zh.wikipedia.org/wiki/%E5%8C%97%E4%BA%AC%E6%97%B6%E9%97%B4）

• DST 夏時制（英語：daylight time，英國與其他地區），又稱夏令時、日光節約時間（英語：daylight saving time, DST，美國），是一種在夏季月份犧牲正常的日出時間，而將時間調快的做法。通常使用夏時制的地區，會在接近春季開始的時候，將時間調快一小時，并在秋季調回正常時間[1]。實際上，夏時制會造成在春季轉換當日的睡眠時間減少一小時，而在秋季轉換當日則會多出一小時的睡眠時間[2][3]。（摘自：https://zh.wikipedia.org/wiki/%E5%A4%8F%E6%97%B6%E5%88%B6）

• 中國夏令時 1986年4月，中國中央有關部門發出“在全國范圍內實行夏時制的通知”，具體作法是：每年從四月中旬第一個星期日的凌晨2時整（北京時間），將時鐘撥快一小時，即將表針由2時撥至3時，夏令時開始；到九月中旬第一個星期日的凌晨2時整（北京夏令時），再將時鐘撥回一小時，即將表針由2時撥至1時，夏令時結束。從1986年到1991年的六個年度，除1986年因是實行夏時制的第一年，從5月4日開始到9月14日結束外，其它年份均按規定的時段施行。在夏令時開始和結束前幾天，新聞媒體均刊登有關部門的通告。1992年起，夏令時暫停實行。（摘自：https://baike.baidu.com/item/%E5%A4%8F%E4%BB%A4%E6%97%B6）

中國夏時制實施時間規定(夏令時) 1935年至1951年，每年5月1日至9月30日。 1952年3月1日至10月31日。 1953年至1954年，每年4月1日至10月31日。 1955年至1956年，每年5月1日至9月30日。 1957年至1959年，每年4月1日至9月30日。 1960年至1961年，每年6月1日至9月30日。 1974年至1975年，每年4月1日至10月31日。 1979年7月1日至9月30日。 1986年至1991年，每年4月中旬的第一個星期日1時起至9月中旬的第一個星期日1時止。具體如下： 1986年4月13日至9月14日， 1987年4月12日至9月13日， 1988年4月10日至9月11日， 1989年4月16日至9月17日， 1990年4月15日至9月16日， 1991年4月14日至9月15日。

通過對比我們可以看到應用中的對應的用戶生日"1988-07-29"剛好在中國的夏令時區間內，因為我們操作系統、數據庫、JDK使用的都是 "Asia/Shanghai" 時區，應該不會錯，通過上圖中debug結果我們也證實了結果是沒問題的。

繼續往外排查業務層和接口層，定位到問題

項目使用的是spring boot提供rest接口返回json報文，使用spring 默認的Jackson框架解析。項目中有需要對外輸出統一日期格式，對Jackson做了一下配置：

#jackson
#日期格式化
spring.jackson.date-format=yyyy-MM-dd HH:mm:ss
spring.jackson.time-zone=GMT+8

我們通過查看 JacksonProperties.java源碼：

//
// Source code recreated from a .class file by IntelliJ IDEA
// (powered by Fernflower decompiler)
//

package org.springframework.boot.autoconfigure.jackson;

import com.fasterxml.jackson.annotation.JsonInclude.Include;
import com.fasterxml.jackson.core.JsonParser.Feature;
import com.fasterxml.jackson.databind.DeserializationFeature;
import com.fasterxml.jackson.databind.MapperFeature;
import com.fasterxml.jackson.databind.SerializationFeature;
import java.util.EnumMap;
import java.util.Locale;
import java.util.Map;
import java.util.TimeZone;
import org.springframework.boot.context.properties.ConfigurationProperties;

@ConfigurationProperties(
  prefix = "spring.jackson"
)
public class JacksonProperties {
  private String dateFormat;
  private String jodaDateTimeFormat;
  private String propertyNamingStrategy;
  private Map<SerializationFeature, Boolean> serialization = new EnumMap(SerializationFeature.class);
  private Map<DeserializationFeature, Boolean> deserialization = new EnumMap(DeserializationFeature.class);
  private Map<MapperFeature, Boolean> mapper = new EnumMap(MapperFeature.class);
  private Map<Feature, Boolean> parser = new EnumMap(Feature.class);
  private Map<com.fasterxml.jackson.core.JsonGenerator.Feature, Boolean> generator = new EnumMap(com.fasterxml.jackson.core.JsonGenerator.Feature.class);
  private Include defaultPropertyInclusion;
  private TimeZone timeZone = null;
  private Locale locale;

  public JacksonProperties() {
  }

  public String getDateFormat() {
    return this.dateFormat;
  }

  public void setDateFormat(String dateFormat) {
    this.dateFormat = dateFormat;
  }

  public String getJodaDateTimeFormat() {
    return this.jodaDateTimeFormat;
  }

  public void setJodaDateTimeFormat(String jodaDataTimeFormat) {
    this.jodaDateTimeFormat = jodaDataTimeFormat;
  }

  public String getPropertyNamingStrategy() {
    return this.propertyNamingStrategy;
  }

  public void setPropertyNamingStrategy(String propertyNamingStrategy) {
    this.propertyNamingStrategy = propertyNamingStrategy;
  }

  public Map<SerializationFeature, Boolean> getSerialization() {
    return this.serialization;
  }

  public Map<DeserializationFeature, Boolean> getDeserialization() {
    return this.deserialization;
  }

  public Map<MapperFeature, Boolean> getMapper() {
    return this.mapper;
  }

  public Map<Feature, Boolean> getParser() {
    return this.parser;
  }

  public Map<com.fasterxml.jackson.core.JsonGenerator.Feature, Boolean> getGenerator() {
    return this.generator;
  }

  public Include getDefaultPropertyInclusion() {
    return this.defaultPropertyInclusion;
  }

  public void setDefaultPropertyInclusion(Include defaultPropertyInclusion) {
    this.defaultPropertyInclusion = defaultPropertyInclusion;
  }

  public TimeZone getTimeZone() {
    return this.timeZone;
  }

  public void setTimeZone(TimeZone timeZone) {
    this.timeZone = timeZone;
  }

  public Locale getLocale() {
    return this.locale;
  }

  public void setLocale(Locale locale) {
    this.locale = locale;
  }
}

得知 spring.jackson.time-zone 屬性操作的就是java.util.TimeZone。于是我們通過一段測試代碼模擬轉換過程：

package com.test;

import java.sql.Date;
import java.util.TimeZone;

/**
 * @author alexpdh
 * @date 2019/07/17
 */
public class Test {

	public static void main(String[] args) {
		System.out.println("當前的默認時區為: " + TimeZone.getDefault().getID());
		Date date1 = Date.valueOf("1988-07-29");
		Date date2 = Date.valueOf("1983-07-29");
		System.out.println("在中國夏令時范圍內的時間 date1=" + date1);
		System.out.println("正常東八區時間 date2=" + date2);
//		模擬 spring.jackson.time-zone=GMT+8 屬性設置
		TimeZone zone = TimeZone.getTimeZone("GMT+8");
		TimeZone.setDefault(zone);
		System.out.println(TimeZone.getDefault().getID());
		Date date3 = date1;
		Date date4 = date2;
		System.out.println("轉換后的在中國夏令時范圍內的時間date3=" + date3);
		System.out.println("轉換后的正常東八區時間 date4=" + date4);
	}
}

運行后輸出結果：

當前的默認時區為: Asia/Shanghai
在中國夏令時范圍內的時間 date1=1988-07-29
正常東八區時間 date2=1983-07-29
GMT+08:00
轉換后的在中國夏令時范圍內的時間date3=1988-07-28
轉換后的正常東八區時間 date4=1983-07-29

從這里終于找到問題發生點了，從debug那張圖我們看出了因為那個日期是在中國的夏令時區間內，要快一個小時，使用了UTC/GMT+0900的格式，而jackjson在將報文轉換為json格式的時候使用的是UTC/GMT+0800的格式。也就是說我們將JDK時區為UTC/GMT+0900的"1988-07-29 00:00:00"這樣的一個時間轉換為了標準東八區的UTC/GMT+0800格式的時間，需要先調慢一個小時變成了"1988-07-28 23:00:00"。

bug解決

定位到問題解決就很簡單了，只需要修改下設置：

#jackson
#日期格式化
spring.jackson.date-format=yyyy-MM-dd HH:mm:ss
spring.jackson.time-zone=Asia/Shanghai

保持時區一致問題得到解決。

到此，相信大家對“怎么排查因JDK導致接口輸出日期格式的時間與預期時間不一致問題”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！