ZoneInfo是Python 3.9+官方推荐的时区方案，直接集成IANA数据库，可直接作为tzinfo参数传入datetime构造函数，无需localize()，避免pytz的易错两步法。
zoneinfo 是 Python 3.9+ 官方推荐的时区处理方案，它直接集成 IANA 时区数据库，无需额外安装依赖，也不再需要 pytz 那套“先获取时区对象、再用 localize() / astimezone()”的易错流程。
zoneinfo.ZoneInfo 代替 pytz.timezone 的基本用法
核心区别在于：ZoneInfo 是一个真正的 tzinfo 子类，可直接传给 datetime 构造函数或 replace() 方法，而 pytz 的 timezone 对象不能直接用于 datetime(..., tzinfo=...)（会出错）。
常见错误现象：用 datetime(2023, 1, 1, tzinfo=ZoneInfo("Asia/Shanghai")) 是合法的；但用 datetime(2023, 1, 1, tzinfo=pytz.timezone("Asia/Shanghai")) 会抛出 AmbiguousTimeError 或静默出错。
- 正确写法：
from datetime import datetime from zoneinfo import ZoneInfo <p>dt = datetime(2023, 10, 29, 1, 30, tzinfo=ZoneInfo("Europe/Berlin")) # DST 切换时刻也安全 - 替换
replace()：naive_dt.replace(tzinfo=ZoneInfo("America/New_York"))—— 直接、无副作用 - 避免用
ZoneInfo做算术运算（如+ timedelta），它不支持；应先转为带时区的datetime再运算
处理夏令时切换（DST）的差异
zoneinfo 在解析本地时间时，对模糊（ambiguous）和不存在（nonexistent）时间的处理更明确，且默认行为与系统一致，不像 pytz 默认强制“早于 DST 结束”的逻辑。
立即学习“Python免费学习笔记（深入）”；
使用场景：处理欧洲/北美用户提交的本地时间字符串（如 "2023-10-29 02:15" 在柏林是模糊时间）。
- 默认行为：
datetime(2023, 10, 29, 2, 15, tzinfo=ZoneInfo("Europe/Berlin"))返回标准时间（UTC+1），即 DST 结束后的那个 2:15 - 显式指定歧义：
ZoneInfo("Europe/Berlin", key="CET")或key="CEST"不被支持；必须用fromisoformat()+fold参数：datetime.fromisoformat("2023-10-29T02:15").replace(tzinfo=ZoneInfo("Europe/Berlin"), fold=1)表示 DST 结束后的第二次 2:15 -
pytz的localize(..., is_dst=None)没有等价物；zoneinfo把决策权交还给fold，更底层、更可控
时区包更新与系统兼容性问题
zoneinfo 依赖操作系统或 Python 内置的 IANA 数据库版本。Python 3.9–3.11 自带的数据通常滞后于最新 IANA 发布（例如 2023c 版本可能未包含 2024 年智利时区变更）。
容易踩的坑：线上环境（尤其 Alpine Linux 或旧版 CentOS）可能缺少 /usr/share/zoneinfo，导致 ZoneInfo("Asia/Shanghai") 报 ZoneInfoNotFoundError。
- 检查数据来源：
import zoneinfo; print(zoneinfo.TZPATH)，确认路径存在且可读 - 生产环境建议显式安装
tzdata包（Debian/Ubuntu）或tzdata（Alpine）；macOS 和 Windows 用户需注意 Python 安装是否自带完整数据库 - 不要依赖
ZoneInfo("UTC")—— 虽然通常可用，但严格来说它不是 IANA 标准名；优先用ZoneInfo("Etc/UTC")或更稳妥的datetime.UTC（Python 3.11+） - 跨平台分发时，若无法保证系统时区数据，可考虑用
pip install tzdata并设置环境变量TZDATA_PATH
真正麻烦的从来不是选 zoneinfo 还是 pytz，而是你是否清楚当前时间字符串来自哪个上下文、有没有 DST 边界、以及部署环境到底加载了哪一版时区规则。
