## 症状现象
服务器上日志的时间戳与真实时间差了整整八小时，凌晨的报警显示在上午，对时间轴排查问题时全部错位；两个系统之间比对日志，同一事件的时间对不上，谁先谁后都说不清。差值恰好八小时，基本可以断定是时区问题：一台机器按 UTC 记时，另一台按东八区，或者应用与系统各用一个时区。跨时区部署与镜像默认 UTC 是这类问题的高发来源。
## 危害场景
时间错位不只是看着别扭。排查故障要拼多台机器的日志时间线，差八小时等于时间线全废；定时任务按错误时区的凌晨三点执行，变成业务高峰跑备份；数据库的时间字段写入与业务预期不符，报表统计整体偏移；证书校验、接口签名带时间戳的鉴权也可能因时区混乱而失败；备份文件落盘的时间戳同样跟着错，事后找文件都费劲。发现日志时间不对，值得立即停下修正，而不是将错就错。
## 修正与验证
先看现状：
bash timedatectl
输出里 Time zone 一行显示当前时区，UTC time 与 Local time 并排给出。修正为目标时区：
bash timedatectl set-timezone Asia/Shanghai
再执行 timedatectl 与 date 各确认一次，Local time 应与北京时间一致。修正后重启相关应用或让它重新加载时区，部分常驻进程启动时缓存了时区，不重启会继续用旧时区记日志。改完顺手把 crontab 里定时任务的执行时间按新时区复核一遍，避免备份窗口悄悄漂移。时区与时间同步是两件事：时区管"怎么显示"，NTP 管"准不准"，两边都要对。
## 预防建议
新机器上线清单里固定两项：set-timezone 统一时区，启用 chrony 或 systemd-timesyncd 做时间同步，让机器既显示对也走得准。应用与数据库连接串里显式声明时区参数，别依赖系统默认，迁移机器或更换镜像时才不会被动。多机环境的日志聚合平台按统一时区展示。在顺云的云服务器上做完初始化就核对一次 timedatectl 输出，这个十秒钟的动作能省掉后面无数对表时间。时区被误改的情况不常见，但发生一次就够受，巡检里带上一行输出成本很低。