datetime.timezone 不能直接用于需要夏令时支持的 tzinfo 参数，因其仅支持固定偏移、不处理 DST；跨时区转换应使用 zoneinfo（3.9+）或 pytz（3.9 以下），仅适合 UTC 等无 DST 场景。
datetime.timezone 不能直接用于 tzinfo 参数？
直接用 datetime.timezone 实例赋给 tzinfo 看似可行，但容易忽略它只支持固定偏移（如 UTC+8），不处理夏令时切换。比如用 datetime.timezone(timedelta(hours=8)) 创建的时区对象，在北京夏令时期间仍返回 +8，而真实 Asia/Shanghai 是全年 UTC+8，无夏令时——这看似巧合正确，但换成 Europe/Paris 就会出错。
真正跨时区转换必须依赖 zoneinfo（Python 3.9+）或第三方库 pytz（3.9 以下）。datetime.timezone 只适合表示无 DST 的简单偏移，比如服务器日志打时间戳用 UTC+0。
- Python 3.9+：优先用
zoneinfo.ZoneInfo("Asia/Shanghai") - Python pytz，用
pytz.timezone("Asia/Shanghai") - 别用
datetime.timezone.utc去“模拟”其他时区——它只是 UTC，不是等价于ZoneInfo("UTC")，但两者在 UTC 场景下行为一致
本地时间转目标时区，为什么总差一小时？
典型错误是把“本地时间字符串”直接套上本地时区再转目标时区，却没意识到系统时区可能和业务要求不一致。比如你在上海，time.localtime() 返回的是系统时区（可能是 CST），但如果你读的是用户提交的“2024-06-15 14:00”，它本意可能是北京时间，而你的脚本运行在 UTC 服务器上——这时 tzlocal.get_localzone() 返回的可能是 UTC，导致解析后时间错乱。
关键原则：所有字符串解析必须显式指定源时区，不能依赖系统或模糊的“本地”。
立即学习“Python免费学习笔记（深入）”；
- 用
datetime.strptime("2024-06-15 14:00", "%Y-%m-%d %H:%M").replace(tzinfo=ZoneInfo("Asia/Shanghai")) - 避免
datetime.now().astimezone(ZoneInfo("Europe/London"))这种写法——now()默认无时区，先得用datetime.now(ZoneInfo("Asia/Shanghai"))显式带时区 - 从数据库或 API 拿到带时区的时间字符串（如
"2024-06-15T14:00:00+08:00"），用datetime.fromisoformat()解析，它能自动识别 offset
zoneinfo.ZoneInfo 和 pytz.timezone 能混用吗？
不能。两者创建的时区对象类型不同，传给 astimezone() 或 replace() 会报 TypeError: incompatible timezone。尤其常见于旧项目升级到 Python 3.9+ 后，保留了 pytz 逻辑但尝试混用 ZoneInfo。
更隐蔽的问题是：pytz 的 localize() 和 astimezone() 行为与 zoneinfo 不同。pytz 要求用 tz.localize(dt) 给 naive datetime 加时区，而 zoneinfo 直接 dt.replace(tzinfo=...) 即可。
- 统一选一个：新项目用
zoneinfo；老项目升级时，把所有pytz.timezone(...)替换为ZoneInfo(...)，并删掉.localize()调用 - 如果必须共存（如调用某旧库返回 pytz 对象），用
dt.astimezone(ZoneInfo("UTC")).replace(tzinfo=None).replace(tzinfo=ZoneInfo("UTC"))强制转换——但这是兜底方案，应尽量避免 -
ZoneInfo支持 pickle，pytz的某些版本不支持，部署到 Celery 等序列化场景时要注意
夏令时切换当天的时间怎么处理？
比如欧洲在 3 月最后一个周日凌晨 1:00 切换到夏令时，时钟跳到 2:00，中间的 1:00–1:59 不存在；10 月则回拨，出现两个 1:00–1:59。用 astimezone() 转换时，Python 默认按“标准时间”解释模糊时间，但实际业务中常需明确策略。
zoneinfo 提供 fold 属性控制：0 表示标准时间，1 表示夏令时。但多数场景下，你应该避免手动构造这种时间，而是让时区数据库自动处理。
- 不要手动写
datetime(2024, 3, 31, 1, 30, tzinfo=ZoneInfo("Europe/Berlin"))—— 这个时间在柏林不存在，会抛ValueError - 用
datetime(2024, 3, 31, 2, 30, tzinfo=ZoneInfo("Europe/Berlin"))安全，因为 2:30 总是存在 - 如果必须处理模糊时间（如用户输入“3月31日 1:30”），需业务层判断：默认按 DST 前还是 DST 后？通常建议提示用户确认，而非代码硬编码
ZoneInfo，只要源头没对齐，后面全错。 
