前提
數據庫時區:GMT+8
show variables like '%time_zone%';
本機電腦時區:
情景一、不指定時區
傳遞的參數映射到Data不指定時區,連接數據庫不指定時區,保存時間以及獲取時間如下:
- 保存時間
傳遞的參數:
{ "date":"2019-11-23T18:30:00" }
注備:GMT 格林威治時間 ,UTC 標准時間,ISO 標准時間,CST 北京時間 ,GMT = UTC ,例如 GMT+8 = UTC+8
時間相差了 8消失,想要保存的是23日6點半,實際保存的是24日2點半。系統日志打印的也是相差了8小時。
測試01:修改計算機時區
再次測試保存時間
系統與數據庫並不受影響,所以系統時間不會影響。如果不指定時區,程序默認使用 CST 中國時區顯示在控制台。而接收的時間默認是 GMT+0
由於認為輸入的時區是0 區,而保存的是+8 區,所以快了8小時
獲取時間:
{ "id": 29, "date": "2019-11-23T18:30:00.000+0000" }
獲取時間是正確的,沒有指定時區,獲取的時區是數據庫GMT8 區是時間,轉換為對象會沒有指定時區是GMT 0區,減去8小時顯示
情景二、指定數據庫連接時區
url: jdbc:mysql://localhost:3306/test?serverTimeZone=GMT+10
測試證明,連接時區對存儲日期不受影響
獲取時間:
測試證明,連接時區對獲取時間沒有影響
此處留作疑問
情景三、指定json 映射時區
spring:
jackson:
time-zone=GMT+5
存儲測試:
{ "date":"2019-11-23T18:30:00" }
系統顯示:
系統日志顯示北京時間23日9點半,比存入時間快了3小時。數據庫也是快了3小時。那么當指定時區時,系統不再使用 0 區,而是將輸入的時間表有時區。
獲取測試:
結果
[ { "id": 34, "date": "2019-11-23T23:30:00.000+0500" }, { "id": 35, "date": "2019-11-23T23:30:00.000+0500" }, { "id": 36, "date": "2019-11-23T18:30:00.000+0500" } ]
只有最后一個時間是正確的,之前的時間都是錯誤的。
錯誤分析:從數據庫獲取的時間是+8 區是時間,現在指定了json 時區,前2者是按0區存儲的,現在顯示的轉換為+5區,導致錯誤偏移了5小時。
情景四、設置全局時區,且設置了json 時區
TimeZone.setDefault(TimeZone.getTimeZone("GMT+5"));
在啟動類上加入時區代碼,保存測試
{ "date":"2019-11-23T18:30:00" }
獲取測試:
[ { "id": 34, "date": "2019-11-23T23:30:00.000+0500" }, { "id": 35, "date": "2019-11-23T23:30:00.000+0500" }, { "id": 36, "date": "2019-11-23T18:30:00.000+0500" }, { "id": 37, "date": "2019-11-23T18:30:00.000+0500" } ]
測試證明,全局時區只是顯示的控制控制台打印的時間,不會影響其他