有情懷，有干貨，微信搜索【三太子敖丙】關注這個不一樣的程式員，
本文 GitHub https://github.com/JavaFamily 已收錄，有一線大廠面試完整考點、資料以及我的系列文章，
前言
在實際業務開發中，會碰到夏令時，閏秒，時區轉換的問題，這些問題都需要從業務角度去考慮，保證用戶在任何地區看到的資料都一致的，這就需要MySQL資料庫、后端服務以及前端服務做相應的處理才能完成，
最近我也剛好在開發的時候遇到了，所幸就寫下這個比較冷門的文章，跟大家聊聊夏令時，閏秒，時區轉換在實際開發程序中的解決方案，
夏令時
夏令時介紹
夏令時（Daylight Saving Time：DST）：又稱"日光節約時制"，是一種為節約能源而人為規定地方時間的制度，在這一制度實行期間所采用的統一時間稱為“夏令時間”，
一般在天亮早的夏季人為將時間調快一小時，可以使人早起早睡，減少照明量，以充分利用光照資源，從而節約照明用電，除了夏令時外還有冬令時，采用的是本地的標準時間，
可以看到意大利是有夏令時制，夏令時的時間從3月28日到10月31日，冬令時（本地標準時間）是從11月1日到3月27日，在夏令時時段內，時間比標準時間快一個小時，例如羅馬市的時區GMT + 1:00，標準時間為10:00:00，在夏令時的時間就是11:00:00，冬令時的時間就是10:00:00，
CET (中歐標準時間) 是UTC + 01:00時區的名稱之一，比UTC（世界標準時間）提前1個小時，與UTC的時間偏差可寫為+01:00，在冬天使用，在夏季時使用CEST - 中歐夏令時間 (UTC + 02:00，提前一個小時)，
LInux時區
Linux服務器的系統時間的校準是通過NTP（Network Time Protocol）服務來實作，每隔一段時間會跟時鐘源進行校對，確保Linux系統時間的準確性，同時Linux作業系統支持不同國家及地區的時區設定，所有時區資訊位于/usr/share/zoneinfo目錄下，如果需要設定時區，只需要將/etc/localtime軟鏈接到一個具體的地區即可，如果這個地區有DST機制，那么Linux會自動在DST和標準時間之間切換，不需要額外的代碼來處理，
## Linux支持的區域資訊
$ ls -ltr /usr/share/zoneinfo/
total 320
lrwxrwxrwx 1 root root 3 10月 23 05:18 Zulu -> UCT
-rw-r--r-- 1 root root 1544 10月 23 05:18 W-SU
-rw-r--r-- 1 root root 1873 10月 23 05:18 WET
lrwxrwxrwx 1 root root 3 10月 23 05:18 UTC -> UCT
lrwxrwxrwx 1 root root 3 10月 23 05:18 Universal -> UCT
-rw-r--r-- 1 root root 127 10月 23 05:18 UCT
-rw-r--r-- 1 root root 1970 10月 23 05:18 CET
## 前端服務所在Linux服務器的時區
$ ls -ltr /etc/localtime
lrwxrwxrwx 1 root root 33 11月 1 06:20 /etc/localtime -> /usr/share/zoneinfo/Asia/Shanghai
通過zdump命令查看下意大利羅馬的時區屬性，
$ zdump -v /usr/share/zoneinfo/CET
/usr/share/zoneinfo/CET Sun Mar 28 00:59:59 2021 UT = Sun Mar 28 01:59:59 2021 CET isdst=0 gmtoff=3600
/usr/share/zoneinfo/CET Sun Mar 28 01:00:00 2021 UT = Sun Mar 28 03:00:00 2021 CEST isdst=1 gmtoff=7200 #2021年夏令時開始
/usr/share/zoneinfo/CET Sun Oct 31 00:59:59 2021 UT = Sun Oct 31 02:59:59 2021 CEST isdst=1 gmtoff=7200 #2021年夏令時結束
Sun Mar 28 01:00:00 2021 UT = Sun Mar 28 03:00:00 2021 CEST isdst=1 gmtoff=7200
從上面的資訊可以看到，2021年夏令時的開始時間是Sun Mar 28 01:00:00，結束時間為Sun Oct 31 00:59:59，isdst = 1說明當前處于DST時段，gmtoff=7200表示與格林治時間的offset，單位秒，即UTC + 02:00，也稱為CEST時間，這說明Linux作業系統已經自動實作了下夏令時DST的自動切換，
處理夏令時
舉個例子，意大利羅馬的客戶需要開發一個稅務系統，用于國內各地市的稅收記賬，由于意大利是有夏令時制，就需要考慮夏令時DST的處理，在開發的程序中，涉及時間問題的包括MySQL資料庫（mysql-server），后端服務（backend-service）以及前端服務（frontend-service）三個方面，下面就從三個層面分析如何去處理DST，
- 前端處理
業務對前端的要求是：不管使用的是移動端還是PC端，都應該正確的顯示當時時間，包括有夏令時制的時間，
如果在中國的話，就比較好處理，沒有DST機制，統一使用東八區即GMT/UTC + 08:00即可，前端服務的時間直接取Linux服務服務器的系統時間，Linux的時區只需要設定為Asia/Shanghai即可，前端不需要做任何時間的轉入轉出，
**轉入：**指POST請求寫入資料，user —> frontend-service —> backend-service —> mysql-server，例如繳稅介面，
**轉出：**指GET請求查詢資料，mysql-server —> backend-service —> frontend-service —> user，例如查詢介面，
不過開心的是，Linux作業系統已經自動實作了DST轉換，在前端不需要做任何處理，設定Linux時區為CET，
# 修改LInux時區為CET，也可以通過timedatectl命令修改，
$ ln -sf /usr/share/zoneinfo/CET /etc/localtime
這樣在意大利國內的用戶的通過終端（移動端或PC端），登錄系統繳稅或查詢時，用戶時間和前端服務的時間完全一致，即完成如下這一步的處理，
- 后端處理
我們了解了前端Linux服務器的時區設定為CET，就能自動處理意大利DST夏令時轉換了，后端Java程式部署在Linux服務器上，將其時區設定跟前端一樣，也是CET時區，后端只需要接收前端傳過來的值進行MySQL的CRUD操作即可，稅務表的結構如下：
CREATE TABLE `tax_form` (
`id` bigint NOT NULL AUTO_INCREMENT COMMENT '主鍵id',
`tax_id` varchar(20) NOT NULL DEFAULT '' COMMENT '稅務編號',
`amount` decimal(12,4) NOT NULL DEFAULT '0.0000' COMMENT '納稅金額',
`tax_payer_id` varchar(20) NOT NULL DEFAULT '' COMMENT '納稅人編號',
`status` tinyint NOT NULL DEFAULT '0' COMMENT '繳稅狀態',
`audit_time` datetime NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '審核時間',
`create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '創建時間',
`update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改時間',
PRIMARY KEY (`id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='稅務記錄表';
主要看一下繳稅和審核介面，分別的對應的SQL陳述句如下：
繳稅
-- 繳稅介面的對應的SQL
insert into tax_form(tax_id,amount,tax_payer_id,status) values('T001', 1234.56, 'U001', 0)
審核
-- 修改審核狀態
update tax_form set status = 1, audit_time = '2021-01-07 12:02:30' where tax_payer_id = 'U001';
涉及時間的欄位有兩類
**公共欄位：**create_time，update_time這些是每個表必須有的時間欄位，而且默認都是MySQL的CURRENT_TIMESTAMP，取的MySQL server的當前系統時間，而這個時間是跟MySQL的時區time_zone設定不同而變化的，同時MySQL也是支持夏令時DST自動轉換的，
業務欄位：audit_time審核時間屬性是由前端頁面傳到后端進行處理，后端無需做任何轉換，
- MySQL處理
MySQL也是支持夏令時DST機制，不過設定時區time_zone只能設定為地區（類似Linux設定時區一樣），不能石永紅MySQL設定的時區的相關變數
mysql> show variables like '%zone%';
+------------------+--------+
| Variable_name | Value |
+------------------+--------+
| system_time_zone | CST | -- 資料庫服務器的當前時區，不可修改，CST這里指的是中國標準時間(China Standard Time UTC+08:00，即東八區)
| time_zone | SYSTEM | -- 資料庫時區，默認跟服務器保持一致，可修改，
目前是東八區，修改為意大利時區，即東一區，
mysql> select now();
+---------------------+
| now() |
+---------------------+
| 2021-01-07 13:43:31
-- 修改資料庫時區為零時區，即，
mysql> set time_zone = 'CET';
ERROR 1298 (HY000): Unknown or incorrect time zone: 'CET'
-- 嘗試通過+0:00方式修改，可以成功修改，
mysql> set time_zone = '+1:00';
Query OK, 0 rows affected (0.00 sec)
MySQL存盤時區資訊的資料字典
mysql> show tables from mysql like '%time_zone%';
+-------------------------------+
| Tables_in_mysql (%time_zone%) |
+-------------------------------+
| time_zone | -- 時區資訊
| time_zone_leap_second | -- 時區閏秒資訊
| time_zone_name | -- 時區名
| time_zone_transition | -- 時區轉換
| time_zone_transition_type | -- 時區轉換型別
默認情況下，這些表都是空的，需要通過MySQL專門提供的命令mysql_tzinfo_to_sql匯入，資料會被插入到表time_zone相關的表中，
# Linux下的時區資訊/usr/share/zoneinfo通過命令mysql_tzinfo_to_sql加載到相關的time_zone表中，
$ mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql
執行完成之后，看一下表中的資料，再嘗試設定時區為CET，
mysql> select * from mysql.time_zone_name where name like '%CET%';
+------+--------------+
| Name | Time_zone_id |
+------+--------------+
| CET | 373 |
-- 設定時區為CET
mysql> set time_zone = 'CET';
Query OK, 0 rows affected (0.02 sec)
mysql> select now();
+---------------------+
| now() |
+---------------------+
| 2021-01-07 10:00:36 |
而且也支持時區轉換，例如將北京時間轉換成羅馬時間，
-- 北京時間17:00:00轉換成CET的羅馬時間就是10:00:00
mysql> select convert_tz('2021-01-07 17:00:00', 'Asia/Shanghai', 'CET') as time;
+---------------------+
| time |
+---------------------+
| 2021-01-07 10:00:00 |
我們要解決的問題是：MySQL設定time_zone='CET’后是否能自動實作DST轉換，如果可以的話，那么用戶端、前端服務、后端服務以及MySQL服務器時區就統一為CET，同時都能自動處理DST，從上面的zdump -v /usr/share/zoneinfo/CET命令輸出可以看到，2021年意大利的夏令時從3月28號01:59:59號開始，也就是時間調快一小時，
-- 01:59:59時間點，沒有發生DST切換，
mysql> select convert_tz('2021-03-28 01:59:59', '+1:00', 'CET') as time;
+---------------------+
| time |
+---------------------+
| 2021-03-28 01:59:59 |
-- 02:00:00時間點，確實發生DST切換，從02:00:00調快了一小時變成了03:00:00
mysql> select convert_tz('2021-03-28 02:00:00', '+1:00', 'CET') as time;
+---------------------+
| time |
+---------------------+
| 2021-03-28 03:00:00 |
-- 將+1:00時間換成CET，結果也是一樣的，發生了DST切換，
mysql> select convert_tz('2021-03-28 02:00:00', 'CET', 'CET') as time;
+---------------------+
| time |
+---------------------+
| 2021-03-28 03:00:00 |
從上面的結果可以看到，當time_zone設定成地區/城市，系統會自動解決夏令時DSTQ切換問題，如果設定time_zone=’+1:00’這種方式就失去了夏令時機制，目前在MySQL資料庫中，在初始化time_zone相關表元資料以后，MySQL就可以自己完成夏令時的修正，不需要額外的服務處理，
對于AWS RDS的來說，time_zone是可以選擇地區/城市的，也就是支持夏令時的自動切換，
- 處理夏令時總結
通過上面的分析可以知道，Linux服務器和MySQL服務器都可以自動處理DST切換，前提是需要設定Linux的時區和MySQL時區為地區，例如都設定為CET，
閏秒
指為保持協調世界時接近于世界時時刻，由國際計量局統一規定在年底或年中（也可能在季末）對協調世界時增加或減少1秒的調整，最近一次閏秒在北京時間2017年1月1日7時59分59秒（時鐘顯示07:59:60）出現，
在實際的業務系統，受閏秒影響的有Linux服務器，Java代碼以及MySQL資料庫，我們來看看它們分別是怎么解決的LeapSecond問題的，
Linux服務器
對于大多數新的linux內核（2.6.x內核以后是支持LeapSecond，在這之前可能會導致Linux Kernel Crash），在設計時都是支持閏秒的，Linux作業系統時間是通過NTP服務來和時鐘源來進行同步，NTP會一級一級地下發閏秒事件通知直到最邊緣的NTP服務器，然后NTP就會把閏秒通知給客戶端的作業系統，由作業系統來處理閏秒通知，
對于閏秒2017-01-01 07:59:60，Linux內核需要處理這個時間，就需要做一些特定的處理，一般會有以下三種方案，
- 后退一秒
- 停止一秒
- 真正的增加一秒
第一種方式會導致一些基于timestamp的訊息通知亂序了，而第二種會導致出現兩個一模一樣的timestamp，而最后一種不會出現timestamp的問題，也是后面Linux內核選擇的處理方案，
mysql> select UNIX_TIMESTAMP('2017-01-01 07:59:59') as nts;
+------------+
| nts |
+------------+
| 1483257599 |
$ date -d '@1483257599' --utc
Sun Jan 1 07:59:59 UTC 2017
$ date -d '@1483257600' --utc
Sun Jan 1 08:00:00 UTC 2017
從這里可以看到，Linux采用的是第三種方案：真正的增加一秒，這也符合業務系統的需求，
Java代碼
Java代碼的System.currentTimeMillis()會產生閏秒60，是取決于Linux作業系統的，在Linux Kernel 2.6.x之后已經fix了LeapSecond問題，
MySQL資料庫
上面看到了在MySQL下已經有了mysql.time_zone_leap_second資料字典，說明已經支持了LeapSecond，處理方案跟Linux類似，
-- 創建一張測驗表存盤timestamp時間戳
CREATE TABLE ls(
id bigint NOT NULL COMMENT 'id',
ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (id));
-- 設定資料庫時區為UTC
mysql> set time_zone = 'UTC';
mysql> set timestamp = 1483257599; --對應時間：2017-01-01 07:59:59
mysql> insert into ls(id) values(1);
mysql> set timestamp = 1483257600; --對應時間：2017-01-01 07:59:60
mysql> insert into ls(id) values(2);
-- 可以看到MySQL對閏秒進行了處理，將07:59:60轉換成了08:00:00，
mysql> select id, ts, unix_timestamp(ts) from ls;
+----+---------------------+--------------------+
| id | ts | unix_timestamp(ts) |
+----+---------------------+--------------------+
| 1 | 2017-01-01 07:59:59 | 1483257599 |
| 2 | 2017-01-01 08:00:00 | 1483257600 |
-- 通過閏秒時間查詢會報錯
mysql> select * from ls where ts = '2017-01-01 07:59:60';
ERROR 1525 (HY000): Incorrect TIMESTAMP value: '2017-01-01 07:59:60'
mysql> select * from ls where ts = '2017-01-01 08:00:00';
+----+---------------------+
| id | ts |
+----+---------------------+
| 2 | 2017-01-01 08:00:00 |
跨境系統的時間處理
上面介紹的意大利羅馬的稅務系統，其實屬于政企業務，只服務于國內的用戶的需求，不涉及海外用戶的請求，相對來說地區和人員都比較固定，但是像這種跨境電商巨頭ebay，它服務的用戶遍布全球各地，而且每個地區的時區不同，同時每個時區的夏令時DST的起始時間也不一樣，我們要解決的是要根據客戶所在地區顯示正確的時間（包括DST），跟前面的DST處理一樣也涉及到三端處理：前端服務（frontend-service），后端服務（backend-service）以及MySQL資料庫（mysql-server），
從這個圖上可以看到，前端服務的UI層跟用戶所在的地區時間要完全一致，至于后端服務和MySQL如何處理時間，對于用戶來說根本不關心的，這就要求前端必須要根據不同地區，不同時區，不同夏令時DST產生不同的時間的用戶進行轉換處理，不同地區的時間轉換目前前端（Vue/React）已經有現成的插件可直接使用，
同時希望只在前端處理用戶時間的轉入和轉出，后端和MySQL資料庫不做任何修改就能完成業務處理和資料存盤，
北京用戶在UTC + 8也就是東八區，而羅馬用戶在UTC + 1東一區，都是在UTC的基礎上做處理，那我們就可以將時區都設定為UTC，然后根據用戶所在地區進行相應的處理，
MySQL處理
設定MySQL資料庫的時區為UTC，不管用戶來自哪個地區存盤在資料庫的時間都是UTC，包括公共時間欄位（創建時間，修改時間）以及業務時間欄位（交易開始時間，交易結束時間），
-- 設定資料庫時區為UTC，即零時區
set global time_zone = 'UTC'
后端處理
MySQL時區是UTC，那么后端服務的所在的Linux Server時區統一設定為UTC，跟MySQL保持一致，這樣后端就不需要做任何轉換，
前端處理
前端拿到標準時區UTC的資料，統一根據用戶所在時區進行轉換，這樣保證與后端資料時區的一致性，前端根據實際情況進行渲染，一般來講，前端將時間資料傳遞到后端，后端封裝成timestamp后存盤在MySQL中對應timestamp型別（MySQL中的timestamp是不區分時區的，例如資料庫是UTC 02:00:00，北京用戶使用ebay在CST 10:00:00下單，資料庫中的訂單表的create_time就應該存盤2020-12-03 10:00:00），同時前端查詢資料的也要做相應的轉換處理，
定時任務
后端服務一般都會一些定時任務，這個時間一般取自Linux OS的時間，跟前端沒關系，基于Linux的UTC時區做相應的調整即可，
總結
上面介紹了夏令時，閏秒以及跨境系統的時間處理問題，主要涉及到MySQL資料庫，后端服務以及前端服務三個層面，對于夏令時，閏秒的轉換處理，Linux和MySQL都可以自動完成處理，不需要額外轉換；對于跨境系統的時間處理，通過設定Linux和MySQL時區為UTC，只需要前端服務處理不同地區用戶時間問題，降低了系統改造的風險，今天就聊這么多，希望對大家有所幫助，
絮叨
敖丙把自己的面試文章整理成了一本電子書，共 1630頁！
干貨滿滿，字字精髓，目錄如下，還有我復習時總結的面試題以及簡歷模板，現在免費送給大家，
鏈接:https://pan.baidu.com/s/1ZQEKJBgtYle3v-1LimcSwg 密碼:wjk6
我是敖丙，你知道的越多，你不知道的越多，感謝各位人才的：點贊、收藏和評論，我們下期見！
文章持續更新，可以微信搜一搜「 三太子敖丙 」第一時間閱讀，回復【資料】有我準備的一線大廠面試資料和簡歷模板，本文 GitHub https://github.com/JavaFamily 已經收錄，有大廠面試完整考點，歡迎Star，
CSDN認證博客專家
CSDN簽約作者
演算法工程師
B站網紅UP
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/251755.html
標籤：java