186、datetime 时区之痛：UTC 最佳实践、pytz vs zoneinfo、DST 转换的隐蔽 bug

186、datetime 时区之痛：UTC 最佳实践、pytz vs zoneinfo、DST 转换的隐蔽 bug一个让我熬夜到凌晨三点的bug先讲个真实故事。去年我负责一个跨境电商的后端服务，订单时间戳全部存的是UTC，前端展示时根据用户时区做转换。一切看起来都很完美，直到有一天，一个巴西用户投诉说他的订单时间显示错了整整一小时。我查了数据库，订单创建时间是2023-10-15 02:30:00 UTC，巴西圣保罗时区是UTC-3，按理说应该是2023-10-14 23:30:00。但前端显示的是2023-10-15 00:30:00。差了一小时。我第一反应是前端代码写错了，结果查了半天，发现是Python的datetime库在作祟。巴西在10月15日正好进入了夏令时（DST），时钟往前拨了一小时。我的代码用了一个过时的时区数据库，根本没意识到那天是DST切换日。这个bug让我意识到：时区处理不是简单的加减偏移量，而是一门玄学。今天就把我踩过的坑和总结的最佳实践全盘托出。为什么说UTC是救星很多新手喜欢这样写：fromd