最近有一個新項目上線，在上線時，突然發現時間與正常時間對不上，少了八個小時；但我絲毫不慌，這不就是個時區的問題嗎，簡單，但是這一次它給我深深的上了一課，一起來看整個排查過程吧。

開始排查

排查數據庫

一般的時區問題都是數據庫配置或數據鏈接參數的配置問題，于是我立馬就定位到了問題，應該是數據庫的時區設置錯了，于是我愉快的查看了數據庫時區

?

命令：show variables like '%time_zone%';

?

1、system_time_zone：全局參數，系統時區，在MySQL啟動時會檢查當前系統的時區并根據系統時區設置全局參數system_time_zone的值。值為CST，與系統時間的時區一致。

2、time_zone：全局參數，設置每個連接會話的時區，默認為SYSTEM，使用全局參數system_time_zone的值。

CST時間

CST時間：中央標準時間。CST可以代表如下4個不同的時區：

Central Standard Time (USA) UT-6:00，美國

Central Standard Time (Australia) UT+9:30，澳大利亞

China Standard Time UT+8:00，中國

Cuba Standard Time UT-4:00，古巴

再次分析

很顯然，這里與UTC時間無關，它只是時間標準。目前Mysql中的system_time_zone是CST，而CST可以代表4個不同的時區，那么，Mysql把它當做哪個時區進行處理了呢？

簡單推算一下，中國時間是UT+8:00，美國是 UT-6:00，當傳入中國時間，直接轉換為美國時間（未考慮時區問題），時間便慢了14個小時。

既然知道了問題，那么解決方案也就有了。

解決方案

方案一：修改數據庫時區

既然是Mysql理解錯了CST指定的時區，那么就將其設置為正確的。

連接Mysql數據庫，設置正確的時區：

set?global?time_zone?=?'+8:00';
set?time_zone?=?'+8:00';
flush?privileges;

再次執行show命令查看：show variables like '%time\_zone%';。

這里我選擇方案2：修改數據庫連接參數

>?基于?Spring?Cloud?Alibaba?+?Gateway?+?Nacos?+?RocketMQ?+?Vue?&?Element?實現的后臺管理系統?+?用戶小程序，支持?RBAC?動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能
>
>?*?項目地址：
>?*?視頻教程：

#?原配置
serverTimezone=GMT%2B8
##修改?serverTimezone=Asia/Shanghai?

url:?jdbc//localhost:3306/aurora_admin?useUnicode=true&characterEncoding=utf8&zeroDateTimeBehavior=convertToNull&useSSL=true&serverTimezone=Asia/Shanghai&autoReconnect=true&rewriteBatchedStatements=true&allowMultiQueries=true

到這里，我想著問題肯定已經解決了；愉快的測了一手；結果還是差八個小時？但是本地項目的時間是正常的啊，我開始有了不祥的預感; 于是我本地連上線上的數據庫開始測試，發現時間是正常的。到這里，就基本排查出不是MySQL的問題。

排查 Linux

我開始懷疑是不是 linux 系統的時區有問題；

?

查看硬件的時間：hwclock --show

?

?

查看系統的時間：date -R

?

發現Linux的時間四年沒問題的，于是開始查服務器的時區配置 查看時區 TZ配置：echo $TZ

發現為空，于是查看系統配置；查看系統配置命令：env

發現確實沒有 TZ 的配置，系統并未設置TZ變量，而是通過localtime指定時區；于是我修改 localtime的指定。

?

先刪除TZ環境變量：unset TZ

?

?

再執行：ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime 命令etc目錄下創建名稱是localtime的快捷鍵指定到上海時區文件上；

?

修改完成后，果斷重啟項目測試，結果令人失望，時間依舊沒有變化，于是嘗試直接加上 TZ配置

?

命令：export TZ=Asia/Shanghai

?

再次查看：

可以看到 TZ配置已經設置成功，到這里我似乎看到了希望；于是再次測試，然后我人傻了，時間依舊少八個小時；到這里，我實在是不知道還有什么是沒排查的了，于是腦海里重新過一遍排查的過程。

1、本地連線上的數據庫測試是正常的，所以數據庫肯定是沒問題的 2、項目程序也沒問題：@JsonFormat(）并沒有指定其他時區，字段類型也對的上；3、Linux時間也沒問題，時區也設置了；

排查Docker

我突然想到項目是通過Docker 來構建的，難道是Docker內部的時區有問題，這是唯一還沒有排查的地方了，于是查看Dockerfile配置文件！

很簡單的配置呀，沒理由出問題呀，為了保險起見；決定手動給他指定一個時區，最終的配置文件；添加配置：

#?安裝tzdata(如果?設置時區不生效使用)
#?RUN?apk?add?--no-cache?tzdata
#?設置時區
ENV?TZ="Asia/Shanghai"

重新構建項目運行，再次測試，時間正常了。

編輯：黃飛