Rails + MySQL 時區陷阱全解析：UTC 與本地時間的正確處理姿勢

雙層時區配置：數據庫與應用必須一致

時區問題源於兩個獨立系統的配置差異：

• MySQL：system_time_zone（OS 級）、time_zone（會話級）。
• Rails：config.time_zone（應用級）、config.active_record.default_timezone（存儲級）。

MySQL 時區操作

-- 查看當前時區
SHOW VARIABLES LIKE '%time_zone%';
-- 臨時設置會話時區（推薦 +8:00）
SET time_zone = '+8:00';
-- 永久生效需修改 my.cnf [mysqld] default-time-zone='+8:00'

Rails 時區配置陷阱

默認行為（UTC 存儲，UTC 讀取）

# config/application.rb
# 無特殊配置時
# 寫入：created_at = Time.now.utc
# 讀取：返回 UTC Time 對象
# 視圖：<%= post.created_at %> → "2012-11-01 05:13:45 UTC"

配置 config.time_zone = 'Beijing' 的誤區

僅影響 寫入時 將 Time.now 轉為本地時間存儲，但 讀取仍返回 UTC 對象，導致視圖顯示需手動轉換。

推薦配置：統一本地時間存儲與讀取

# config/application.rb
config.active_record.default_timezone = :local  # 存儲本地時間
config.time_zone = 'Beijing'                    # 應用級時區

效果：

• 寫入：INSERT ... created_at = '2012-11-01 13:13:45'（北京時間）。
• 讀取：post.created_at 返回帶時區的 Thu, 01 Nov 2012 13:13:45 CST +08:00。
• 數據庫查詢直接看到本地時間，無需心智轉換。

視圖層格式化最佳實踐

Rails Console 的特殊行為

> p = Post.last
# SQL 查詢日誌顯示 UTC：created_at: "2012-11-01 05:39:26"
> p.created_at
# 實際返回對象：Thu, 01 Nov 2012 13:39:26 CST +08:00

ActiveRecord 會根據 config.time_zone 自動將數據庫 UTC 值轉換為本地 ActiveSupport::TimeWithZone 對象，直接使用對象方法（如 strftime、localtime）即可。

避坑指南：跨系統時區一致性檢查清單

1. OS 時區：date / timedatectl 確認 CST。
2. MySQL：SELECT NOW(); 對比 OS 時間。
3. Rails：rails runner "puts Time.now, Time.zone.now" 雙輸出對比。
4. 部署腳本：Dockerfile ENV TZ=Asia/Shanghai、RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime。
5. 定時任務：Whenever/Sidekiq-cron 確認調度時區與應用一致。

總結

時區問題的核心是 存儲層、應用層、展示層三端統一。推薦策略：

• 數據庫存儲本地時間（default_timezone = :local），直觀易維護。
• 應用層統一時區（config.time_zone），ActiveRecord 自動處理轉換。
• 視圖層使用 localtime 或 I18n l 助手，拒絕手動 + 8.hours 硬編碼。

「UTC 存儲、本地顯示」雖是學院派推薦，但在中小型國內項目中，「本地時間全鏈路」能大幅降低認知負擔與 Bug 率。選擇權在團隊，關鍵是全鏈路一致。