服務器時間是最不起眼的配置之一，很多人装完系統就没再看過它。但它同时牵着前台顯示、後台日誌、定时任務，以及蜘蛛讀到的 lastmod。时区對不上，問题不會立刻炸出来，而是慢慢變成“發布時間怪怪的”“日誌對不上号”這類说不清的小毛病。
时区没统一，先乱的是發布時間
一台服務器上通常有三层時間：操作系統、執行环境（比如 PHP 的 date.timezone）、資料库。三层各寫各的时区，前台就會看到奇怪的结果——晚上十一点發的文章顯示成第二天早上七点，或者干脆顯示一個“未来時間”。讀者未必在意，但編輯回看歷史内容时會很混乱，排期和更新节奏也跟着错。
比較省事的做法是：存储统一用 UTC，展示时再按站点主要訪客所在时区轉換。如果嫌麻烦，至少保證系統、應用、資料库三层一致，並把结论寫進运维记錄，別让下一個人再猜一遍。
時間错乱容易在哪些地方露头
- 文章發布時間、评论時間、用戶註冊時間
- Sitemap 與 RSS 里的 lastmod、pubDate
- 訪問日誌的時間戳，直接决定你怎么判断蜘蛛的到訪規律
- 备份、清理缓存、生成静態頁等定时任務
- 證书到期提醒、缓存過期時間等依赖時間的配置
排查顺序建议：先看系統時間，再看應用时区，然後看資料库，最後看日誌輸出。一层一层對，比到處乱翻快得多。
和蜘蛛有關的两個细节
lastmod 不要随口寫
有些 CMS 會在儲存、換模板甚至全站重建时，把所有頁面的修改時間刷成目前時間。蜘蛛第一次来可能還會多跑几趟，發現内容根本没變之後，對 lastmod 的信任就會打折。反過来，頁面确實改了却一直不更新 lastmod，蜘蛛也没有理由優先重訪。老實记錄比“看起来很勤快”有用。
日誌時間對不上，分析就白做
服務器日誌常用 UTC，而你在本地時間下午三点打開看，看到的可能是早上七点的记錄。跨天統計抓取量、判断蜘蛛集中到訪的时段、對照自己几点發的内容，都會偏一截。没看出問题，往往只是因為偏差刚好是整數小时，不容易察觉。
一次十分钟的自查
- 在服務器上执行 date 和 timedatectl，確認目前時間與时区。
- 检查執行环境和資料库连接使用的时区，是否與系統一致。
- 發一條測試内容，對比後台、前台、資料库里记錄的三個時間。
- 取一段訪問日誌，看時間戳與目前時間的差值是不是整小时。
- 查看定时任務最近几次的實际执行時間是否符合预期。
- 確認證书到期、缓存過期這類提醒没被时区带偏。
- 把结论记下来：统一用哪個时区、在哪里改，避免下次又改回去。
顺手的几個小調整
给編輯看的時間用本地时区，對外輸出的時間（RSS、sitemap、HTTP 响應头）尽量用带时区的 ISO 8601 格式，减少解析歧义。開啟 NTP 同步，避免服務器長時間執行後慢慢跑偏。改完时区後要专门检查一遍定时任務，有些任務會在改動的那一刻被触發一次，甚至干脆错過。
時間不出問题的时候，没有人會夸它。真出問题时，往往是一串连鎖反應：編輯以為内容没發出去，运营以為蜘蛛没来，技術以為程序有 bug。花十分钟核對一次，比事後翻日誌找原因划算得多。