计划任务晚跑了八小时，原因很低级

有个每天早上要跑的计划任务，前段时间我发现它跑出来的结果不对劲。任务本身没报错，日志也正常，就是时间对不上：本该早上七点出的结果，每天都是下午三点才躺在目录里，整整晚了八个小时。

八个小时，这个数字其实已经把答案写脸上了。但我当时没往那儿想，先怀疑了一圈别的：是不是 cron 服务没起来，查了，在跑；是不是脚本里写死了什么奇怪的延时，翻了一遍，没有；是不是机器负载高把任务拖了，看了眼历史负载，低得很。一圈查完，啥毛病没有，我盯着屏幕愣了一会儿，才想起来敲 `timedatectl`。

果然。系统时区是 UTC。

这台机器重装过一次系统，云厂商的镜像默认给的是 UTC，我装完就闷头部署服务，时区这事压根没想起来。cron 是按系统本地时间触发的，我脑子里想的是北京时间七点，它按 UTC 七点跑，换算过来正好是下午三点，一分钟都不差。这一个月它其实每天都很守时，只是守的不是我的时。

改起来就一条命令的事，时区设成 Asia/Shanghai，再把任务头几天盯了一眼，时间对上了，这事就算完了。

后来我新开机器，初始化的清单里多了一项：时区。跟改密码、配密钥这些放在一起，都是装完系统先做的事。以前我觉得时区这种东西无所谓，服务能跑就行，现在知道了，凡是跟"几点"沾边的功能——计划任务、日志里的时间戳、证书校验，还有定时备份——全都是按系统时区算的。时区不对，平时看不出来，等你靠时间去排查问题的时候，日志里的时间都是错的，那个误导性才叫大。

其实类似的低级坑还有不少。比如新机器的时间同步没开，时钟慢慢漂，漂到跟标准时间差出好几分钟，接口签名就开始报错。这种问题排查起来都有个共同点：一路查上去全是好的，最后发现错在最底层、最不起眼的那一层。所以我现在的习惯是，遇到时间相关的怪事，先别急着翻代码，把 `date` 和 `timedatectl` 敲一遍再说，一分钟的事，能省掉后面一小时的白忙。