系統設計中跨時區問題的解決方案
一、背景
假如開發一套統一的系統產品，供遍布全球的所有分公司使用。
產品功能設計中，經常會遇到一場活動，分跨不同時區，系統需要顯示不同時區的時間，同時希望跨時區的用戶可以同一時間開始，同一時間結束。
對于類似跨時區處理問題，那我們該如何設計實現呢？
二、幾個重要概念
- 時區
劃分時區是為了便于人們進行跨地區的交流、協作和管理。
時區的劃分以地球表面按經線從東到西劃成一個個區域，每隔經度15°劃分一個時區，規定相鄰區域的時間相差1小時，如下圖所示：
圖片
- 格林尼治時間
英國皇家格林尼治天文臺，UTC/GMT 0 (零時區)。
- 中國時區
有東五區、東六區、東七區、東八區、東九區，新疆在東五、東六、而東北在東九區，但解放后我們國家統一采用北京時間（東八區）為準。
- UTC
Coordinated Universal Time，世界統一時間，中國是UTC+8。
- GMT
Greenwish Mean Time，以地球公轉和自轉來計算時間，而UTC以原子鐘來計算時間。
- UNIX時間戳
1970年1月1日（UTC/GMT的午夜）開始所經過的秒數，因此，不同的時區的時間戳是相同的。
三、操作系統、數據庫時區設置
3.1 Linux 中設置時區
一臺Linux服務器有兩個時間源，一個是硬件時間，即服務器硬件CMOS維護的時間，還有一個是軟件時間，即操作系統維護的時間，前者通過hwclock命令來訪問，后者則主要通過date命令來訪問。
date是最常用的時間相關的命令，例如：
# 獲取當前時間
$ date
Fri Apr 26 15:22:16 CST 2024
# 以特定格式輸出當前時間，格式字符串前以"+"開頭，例如獲得當前時間的epoch
$ date +%s
1714117833
# 設置當前時間
$ sudo date -s "2024-04-25 00:00:00"
Thu Apr 25 00:00:00 CST 2024如果是云服務器的話，中國區服務器默認都是UTC+8，海外機器則是UTC+0，關于這個大家再需要確認一下。
Linux 使用 tzselect 調整時區
該命令會向導式的選擇洲區、國家和城市，然后在/usr/share/zoneinfo下會生成時區的文件，將該文件覆蓋/etc/localtime即可完成時區設置。
#設置時區
tzselect3.2 MySQL 中設置時區
先登錄到mysql 安裝所在的機器。
-- 看下當前的mysql時區設置
show variables like "%time_zone%";下圖顯示 SYSTEM，表示用的默認時區。
圖片
我們可以修改成 +8 的北京所在時區，操作如下：
set global time_zone = '+8:00';
set time_zone = '+8:00';如上修改，MySQL如果重啟后，又會恢復之前的設置。
下面介紹一種設置，讓重啟永久生效的方案：修改設置，重啟永久生效。
修改配置文件 /etc/my.cnf
[mysqld]
default-time_zone = '+8:00'重啟 MySQL 生效
systemctl stop mysqld.service
systemctl start mysqld.service四、系統跨時區設計
現在我們回到正規，談談如何解決上面開篇提出的問題。
4.1 服務端中的時間處理
既然時區的處理不能在客戶端做，換言之就必須在服務端實現。
這樣就需要解決兩個問題：時間的保存和獲取。
客戶端傳來的時間為客戶端所在時區的當地時間，服務端接收到客戶端發送的時間后，需要基于客戶端相應時區轉換成UTC時間才能保存到數據庫。
圖片
所有后端暴露的接口中的時間對象，全部以 UTC 時間表示。
同時，所有后端在存儲、計算、傳輸時間時，也統一使用 UTC 時間。由于 DB 存儲時間時，時區信息會被丟掉，因此應保證丟掉的時區，是大家明確約定清楚的無歧義的，即 UTC。這樣一來，數據庫中的所有時間字段也都沒有歧義。
4.2 前端中的時間
時間在前端中的應用比較簡單，通常的方案是：后端直接返回 ISO 標準本地時間，避免 UTC 在前端再次格式化和處理時區，否則會把問題變得更加復雜（時區設置只發生在應用服務器中）。
如果有需要處理跨時區的業務場景需，可以讓用戶選擇時區，并在任何時候都將處理后的時區信息放到時間字符串中。
圖片
前端的時間格式化比較簡單，可以使用 Day.js 和 Moment.js 等時間庫來完成。
正是因為前面講到的時區問題，Moment.js 為了處理此問題，使用了一個巨大的 JSON 文件記錄了不同年份之間、不同國家、不同經緯度的時區信息，另外這些信息還會和語言信息綁定導致文件非常巨大。
4.3 其它注意事項
在編程中還有一些額外的坑可能需要注意：
- 使用環境變量配置時區信息，使用應用服務器來裁決時區（沒有特別業務說明的情況下），因此確保服務器配置的時區相同。
- 如果是跨國交易或者數據同步的時候，根據客戶端連接到的服務器來決定操作用戶所屬的時區。
- 依賴應用服務器的時區信息做時區裁決，不要依賴數據庫的時區設置，數據庫透明存放數據即可。
- 時區配置來源有操作系統、環境變量、數據庫時區、Java 啟動參數，建議統一使用 Java 啟動參數，避免配置出錯，數據庫不要做時區自動轉換，避免使用 TIMESTAMP 類型。
- 在高并發的場景中獲取系統時間可能有性能問題，原因是 JVM 需要訪問進入系統內核態執行指令，當高并發且不需要高精度時間時可以增加緩存，但需要權衡處理。
- 有時候在處理業務時，需要考慮自然月問題，需要特別注意。
- 關于時間同步問題中，還有一個墻上時鐘和單調時鐘的問題。墻上時鐘是指根據日歷獲取時間，會受到時間校對回撥的問題，而單調時鐘是指系統啟動后的秒數，它不會回撥。在使用 NTP 服務時，可以配置為 NTPD 模式，通過調慢時間頻率避免回撥。
五、補充知識：夏令時、冬令時
圖片
夏令時（Daylight Saving Time：DST），也叫夏時制，又稱“日光節約時制”和“夏令時間”，是一種為節約能源而人為規定地方時間的制度，在這一制度實行期間所采用的統一時間稱為“夏令時間”。一般在天亮早的夏季人為將時間調快一小時，可以使人早起早睡，減少照明量，以充分利用光照資源，從而節約照明用電。
夏令時調整通常適用于：夏季日照時間相對較長，日出和日落時間發生較大變化的地方。關于夏令時的問題，人們褒貶不一。
有夏令時就會有冬令時，冬令時 通常是指當地使用的標準時間。在使用夏令時 - 日光節約時制(Daylight Saving Time) 的地區，夏天時鐘撥快一小時，冬天再撥回標準時間。
那為什么我國沒有夏令時呢？
其實不使用夏令時也能實現節約能源、減少照明成本的目的，只不過把調整人們生活節奏的權利給到了具體場景。在學校，會使用夏季和冬季課表，在工作環境中，某些公司也會針對下冬夏調整上班時間。
六、閱讀更多及參考文獻
本文參考資料：
