聊聊當業務數據時間和預期的不一樣，可以從哪些方向排查
前言
前些天業務部門的開發同事遇到了一個奇怪的bug，首先他們有個業務已經入庫的創建時間和服務器時間相差了8個小時，其次當這個時間顯示到前端后，這個時間竟然和服務時間相差了好幾個月。
今天就這個問題，來做個復盤，來聊聊當業務數據時間和預期的不一樣，可以從哪些方向排查
排查方向
1、數據庫和服務器的時間不一致
1、查看jdbc鏈接配置的時區，即serverTimezone的參數配置
注： 本文的時區都以東八區為基準，且數據庫為mysql
示例：
- jdbc:mysql://localhost：3306/demo?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=UTC
如上圖配置的時區是UTC，這樣就和東八區相差8個小時。如果按這種配法，當我們在代碼層采用new Date()的方式，則落到數據庫的時間會比我們預期的時間相差8個小時。此時我們可以把jdbc上配置的時區參數改成
- serverTimezone=Asia/Shanghai
2、查看數據庫默認的時區配置
- show variables like '%time_zone%';
由圖可以看出，此時數據庫時區默認配置不是東八區。我們可以通過如下方法進行修改
a、通過命令
- ##修改mysql全局時區為東八區
- set global time_zone = '+8:00';
- ##修改當前會話時區
- set time_zone = '+8:00';
注： 通過命令行，無需重啟mysql服務，但當mysql服務再次被重啟，則上面的配置就會消失
b、通過配置文件
linux系統則編輯my.cnf ，填入如下內容
- [mysqld]
- // 設置默認時區
- default-time_zone='+8:00'
window的系統則編輯my.ini，填入的內容和linux一樣
注： 修改完配置后，需要重啟mysql服務
業務部門的創建時間相差8個小時，就是因為他們業務的創建時間統一是通過數據庫配置默認時間，當時他們數據庫默認時區是UTC，因此相差了8個小時。后來通過調整數據庫時區解決這個問題
2、容器和服務器的時間不一致
1、進入容器內部查看時間
- docker exec -it 【容器ID或者NAME】 bin/bash -c date
2、如果是容器是已經生成
可以直接把宿主機的localtime拷貝到docker容器中，前提是宿主機的時間也是對的。命令如下
- docker cp /etc/localtime 【容器ID或者NAME】:/etc/localtime
或者直接修改docker容器的時間也可以。進入容器內容，執行date -s
3、容器生成前，直接通過dockerfile配置【推薦】
- FROM adoptopenjdk/openjdk8
- VOLUME /tmp
- #ENV JAVA_OPTS="-Dcom.sun.management.jmxremote.port=39083 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"
- ENV JAVA_OPTS=""
- COPY localtime /etc/localtime
- RUN echo "Asia/Shanghai" > /etc/timezone
- COPY demo-biz/target/demo-service-biz-*.jar app.jar
- ENTRYPOINT [ "sh", "-c", "exec java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app.jar" ]
注： 因業務的dockerfile是統一根據模板生成，因此就沒這個問題
3、時間格式配置不正確
業務部門為了統一處理時間格式，在代碼中做了如下配置
- @Configuration
- public class WebConfig implements WebMvcConfigurer {
- @Override
- public void configureMessageConverters(List<HttpMessageConverter<?>> converters) {
- FastJsonHttpMessageConverter fastConverter = new FastJsonHttpMessageConverter();
- //格式化json數據格式
- FastJsonConfig fastJsonConfig = new FastJsonConfig();
- //序列化時避免精度丟失，轉換為字符串
- SerializeConfig serializeConfig = SerializeConfig.globalInstance;
- serializeConfig.put(BigInteger.class, ToStringSerializer.instance);
- serializeConfig.put(Long.class, ToStringSerializer.instance);
- serializeConfig.put(Long.TYPE, ToStringSerializer.instance);
- fastJsonConfig.setSerializerFeatures(SerializerFeature.WriteMapNullValue);
- fastJsonConfig.setSerializeConfig(serializeConfig);
- fastJsonConfig.setDateFormat("yyyy-HH-dd HH:mm:ss");
- fastConverter.setFastJsonConfig(fastJsonConfig);
- List<MediaType> fastMediaTypes = new ArrayList<>();
- fastMediaTypes.add(MediaType.APPLICATION_JSON_UTF8);
- fastMediaTypes.add(MediaType.APPLICATION_JSON);
- fastConverter.setSupportedMediaTypes(fastMediaTypes);
- converters.add(0,fastConverter);
- }
- }
眼尖的朋友，可能發現了那個時間格式，長得和正常的格式是不一樣的。誰能想到，那個奇葩的bug，竟然是因為不小心把時間格式寫錯了。解決的方法就很簡單了，
- fastJsonConfig.setDateFormat("yyyy-HH-dd HH:mm:ss");
改成
- fastJsonConfig.setDateFormat("yyyy-MM-dd HH:mm:ss");
總結
上面就介紹幾種排查方向，尤其是最后一種，因為時間格式寫錯，導致時間顯示錯誤
