前阵子写了个每天跑的定时任务，逻辑很简单，本地测了没问题就直接上去了。结果有天半夜被报警叫醒，说同一份任务跑了两遍。
查了半天才反应过来，我一直在把服务器时间当"本地时间"用。服务器是UTC，我在东八区，定时写在"凌晨三点"——这个三点到底是哪里的三点？赶上夏令时，时差还飘。代码里的时间是naive的，不带任何时区标记，全靠一种"大家都懂的默契"。默契个鬼。
呵呵说真的，时间这种东西，不显式带时区就是给自己埋雷。现在我一律存UTC，显示再转本地，多打几个字母比半夜爬起来香多了。离谱的是这坑我居然踩了两次，대박。你们有没有被 timezone 整过的？
东八区从1991年就不搞夏令时了，所以"时差飘"那块不是夏令时的锅，纯粹是naive datetime没带tz标记。
还有个坑你没提到：cron是按它自己环境的时区跑调度的，代码里存UTC救不了触发时间。要么给cron环境显式设TZ，要么排期直接写UTC时刻，别在本地时间和UTC之间玩换算。
我之前也中过招，现在定时任务全用UTC排，显示再转本地。대박，这坑谁踩谁知道。
naive datetime 就是定时炸弹，早晚炸。其实
你踩两次不冤，这坑太经典了。根因就一个：时间字符串没带时区信息，调度器和服务器各按各的理解跑。
其实
存UTC、显示再转本地这个思路没问题，但光靠自觉不够稳。建议直接上 tz-aware 的对象。Python 的话别用原生 datetime.now()，换 datetime.now(timezone.utc)，或者直接用 pendulum 库，默认就是带时区的，想写错都难。
定时任务那边，crontab 本身不带时区概念，全靠系统环境。如果你用的是 systemd timer，可以在 unit 文件里指定 Timezone=Asia/Shanghai。要是用 APScheduler 之类的库，初始化 scheduler 的时候把 timezone 参数写死，别留空让它去猜。
另外夏令时那个点，很多人以为东八区没有夏令时就安全了。但只要你的业务涉及海外用户或者跨国节点，照样会翻车。去年我追的一个团回归，打歌舞台的直播时间就因为欧美切夏令时，好几个站子通知全搞错了，粉丝在直播间干等一小时。连追星都能被时区背刺，更别说跑任务了。
多打几个字母确实比半夜爬起来香。奶茶续命也得有命喝才行。你现在用的什么调度框架？
你这个"踩了两次"才是重点吧，第二次到底是什么情况？我赌是后来迁服务器或者换了云环境，代码一行没动，可老一套"默契"早就不适用了。
突然想到夏令时才是真阴险。UTC自己倒是干净，可只要你某处偷偷按本地夏时制算了，或者哪个库自作主张帮你跳了钟，debug的时候人是真懵。我早年在不同国家之间跑，光是跟人约电话就吃过好几次亏，明明说好"早上九点"，结果一个按summer time一个按standard，永远差一小时，能气一整天。
你现在全存UTC再转本地算把雷拔了，不过显示那层也得统一管住，不然前端后端各转各的，迟早又给你来一出。
被timezone整过的人举手。我之前也碰到过时间对不上的情况，后来才明白多打几个字母真比半夜爬起来香。辛苦了楼主，现在统一UTC就安心多啦。
存UTC只是把数据层理顺了。cron那层时区不写死，凌晨三点的触发时机照样飘。而且UTC不吃夏令时，时差飘的锅真不在存储端。
踩两次最有料！第一次改完UTC，第二次是换项目又忘，还是老代码没清干净？我怎么觉得你那"默契"根本没断 (￣▽￣)
半夜被报警叫醒也太辛苦了。那种"默契"我也曾天真信过，后来乖乖全存UTC才踏实。被时区坑过的人懂你 (＾▽＾)