Python datetime时区转换为何受本地UTC偏移与DST影响

你观察到的所有现象都符合datetime模块的设计规则，不存在异常，核心逻辑分点说明如下：

1. naive datetime 调用astimezone()的隐式规则 #

当对tzinfo=None的naive datetime对象调用astimezone(target_tz)方法时，Python 会默认将该naive时间视为运行环境系统本地时区的时间，再执行到目标时区的转换。
你本地运行naive.astimezone(datetime.timezone.utc)得到的UTC时间比输入的naive时间早2小时，就是因为你本地Linux系统配置的时区为夏令时阶段的中欧时区（UTC+2），因此8:02:34的本地时间转UTC会自动减2小时得到6:02:34，和你代码注释里假设的“naive对象代表UTC时间”没有关系——这个隐式读取系统时区的行为是方法本身的固定逻辑，不会因为你对naive对象的语义预设而改变。

2. 原生datetime.timezone是固定偏移实现，不支持DST #

你通过datetime.timezone(datetime.timedelta(hours=1))创建的时区对象是静态固定偏移时区，从设计上就不存储任何夏令时规则，也不会根据传入的日期动态调整UTC偏移量，调用其dst()方法永远返回None。
这就是你测试冬、夏令时日期都得到固定+1:00偏移的根本原因：这个类仅能表示类似UTC这种偏移永远不变的时区，根本无法承载带DST切换的真实地理时区逻辑，用它做中欧时区转换必然得到错误结果。

3. zoneinfo 正确处理DST的原因 #

Python 3.9 新增的zoneinfo.ZoneInfo是基于标准IANA时区数据库实现的地理时区类，会加载对应时区全量的历史、未来偏移规则，包括每年DST的切换时间点、偏移变化量。因此传入Europe/Berlin时，它能正确识别2022年7月属于夏令时（UTC+2，DST偏移1小时）、1月属于冬令时（UTC+1），转换结果自然符合预期。

4. 不同运行环境结果差异的来源 #

你在Python官方在线Shell中运行同一段代码得到不同输出，核心原因是不同运行环境的系统本地时区配置不同：

• 你本地Linux环境配置为Europe/Berlin时区，naive时间会被按UTC+2（夏令时）处理
• 官方在线Shell的运行容器默认时区通常为UTC，naive时间会被按UTC+0处理，转换结果自然和本地运行有差异

• 不要用naive datetime承载有明确时区语义的时间，创建时间对象时就明确绑定对应时区，避免依赖astimezone()对naive对象的隐式系统时区假设
• 所有涉及真实地理时区、需要处理DST切换的场景，不要手动创建固定偏移的datetime.timezone对象，直接使用zoneinfo.ZoneInfo加载对应IANA时区即可
• Python 3.10及以上版本可以直接通过zoneinfo.ZoneInfo("localtime")获取带完整DST规则的系统本地时区对象，不要硬编码固定时区偏移。

内容的提问来源于stack exchange，提问作者handle