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

開始排查

排查數(shù)據(jù)庫

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

?

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

?

1、system_time_zone：全局參數(shù)，系統(tǒng)時區(qū)，在MySQL啟動時會檢查當前系統(tǒng)的時區(qū)并根據(jù)系統(tǒng)時區(qū)設置全局參數(shù)system_time_zone的值。值為CST，與系統(tǒng)時間的時區(qū)一致。

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

CST時間

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

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個不同的時區(qū)，那么，Mysql把它當做哪個時區(qū)進行處理了呢？

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

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

解決方案

方案一：修改數(shù)據(jù)庫時區(qū)

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

連接Mysql數(shù)據(jù)庫，設置正確的時區(qū)：

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

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

這里我選擇方案2：修改數(shù)據(jù)庫連接參數(shù)

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

#?原配置
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

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

排查 Linux

我開始懷疑是不是 linux 系統(tǒng)的時區(qū)有問題；

?

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

?

?

查看系統(tǒng)的時間：date -R

?

發(fā)現(xiàn)Linux的時間四年沒問題的，于是開始查服務器的時區(qū)配置 查看時區(qū) TZ配置：echo $TZ

發(fā)現(xiàn)為空，于是查看系統(tǒng)配置；查看系統(tǒng)配置命令：env

發(fā)現(xiàn)確實沒有 TZ 的配置，系統(tǒng)并未設置TZ變量，而是通過localtime指定時區(qū)；于是我修改 localtime的指定。

?

先刪除TZ環(huán)境變量：unset TZ

?

?

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

?

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

?

命令：export TZ=Asia/Shanghai

?

再次查看：

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

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

排查Docker

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

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

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

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

編輯：黃飛