zoneinfo 更推荐用于新项目，因其是 Python 3.9+ 内置模块，直接对接 IANA 数据库、无需额外依赖、符合 PEP 615，且避免 pytz 的 localize/astimezone 陷阱，时区附加更直观安全，ZoneInfo 实例不可变且可哈希。
zoneinfo 为什么比 pytz 更推荐用于新项目
Python 3.9+ 内置 zoneinfo 模块，直接对接 IANA 时区数据库，无需额外安装依赖，且设计更符合 PEP 615 规范。它避免了 pytz 中常见的「先 localize 再 astimezone」陷阱，时区附加逻辑更直观——直接用 ZoneInfo 实例作为 tzinfo 参数即可。
常见错误现象：用 pytz.timezone('Asia/Shanghai').localize(dt) 处理已有时区的 datetime，会抛出 AmbiguousTimeError 或 NonExistentTimeError；而 zoneinfo 对同一时间点多次调用 replace(tzinfo=...) 或 astimezone(...) 是安全的。
-
ZoneInfo实例是不可变的、可哈希的，适合做字典键或缓存键 - 不支持 Python pip install backports.zoneinfo 补充
- Windows 用户注意：IANA 数据库路径可能未自动识别，首次使用时若报
ZoneInfoNotFoundError，需手动设置环境变量TZDATA_DIR指向解压后的 tzdata 目录
如何安全地把本地时间转成 UTC（带夏令时感知）
关键点在于：不能假设本地系统时区 = 当前业务时区。必须显式指定源时区，否则 datetime.now().astimezone(timezone.utc) 依赖 time.tzname，在容器或 CI 环境中常为空或错误。
正确做法是用 ZoneInfo 显式绑定源时区后再转换：
立即学习“Python免费学习笔记（深入）”；
from datetime import datetime
from zoneinfo import ZoneInfo
<h1>错误：依赖系统时区，不可靠</h1><p>dt_naive = datetime(2024, 3, 15, 14, 30)
dt_local = dt_naive.replace(tzinfo=ZoneInfo('Asia/Shanghai')) # ✅ 绑定时区
dt_utc = dt_local.astimezone(ZoneInfo('UTC')) # ✅ 转换
- 永远不要对 naive datetime 直接调用
astimezone()，会隐式使用系统时区，行为不可控 -
ZoneInfo('Asia/Shanghai')不受夏令时影响（中国已多年不实行），但ZoneInfo('Europe/Paris')会自动处理 CET/CEST 切换 - 如果输入是字符串，先用
datetime.fromisoformat()解析，再replace(tzinfo=...)，不要用strptime配%Z——它无法可靠识别时区缩写
跨时区比较和算术运算要注意什么
datetime 的 +、-、< 等操作要求两个对象都带时区（aware），否则抛 TypeError: can't compare offset-naive and offset-aware datetimes。但即使都带时区，也要小心 ZoneInfo 实例是否来自同一数据源。
典型问题：从数据库读出的 timestamp with time zone 字段，在 psycopg3 中默认返回 datetime + ZoneInfo，但若该 ZoneInfo 是用字符串动态构造（如 ZoneInfo(row['tz'])），而 row['tz'] 是用户输入的 'GMT+8' 这类非法 IANA 名，则运行时报 ZoneInfoNotFoundError。
- 所有参与比较或计算的 datetime 必须用合法 IANA 时区名（如
'America/New_York'，而非'EST'或'UTC+5'） - 跨时区减法得到的是
timedelta，不含时区信息，结果恒为绝对秒数，无需额外处理 - 用
datetime.combine(date, time, tzinfo=...)构造带时区时间时，确保date和time本身不携带冲突时区语义
生产环境部署时 zoneinfo 的常见坑
zoneinfo 的可靠性高度依赖底层 tzdata 版本。不同系统预装的 tzdata 年份差异很大：Ubuntu 22.04 自带 2022a，而 Alpine Linux 3.18 只有 2022g——这意味着它们对 2023 年以后的时区变更（如 Chile 2023 年取消夏令时）认知不一致。
表现就是：同一段代码在开发机上输出正确时间，在 Kubernetes Pod 里却差一小时。
- 在 Dockerfile 中显式升级 tzdata：
RUN apk add --no-cache tzdata && cp -f /usr/share/zoneinfo/UTC /etc/localtime（Alpine）或apt-get install -y tzdata（Debian） - 用
zoneinfo.available_timezones()检查运行时是否真包含所需时区（例如'Australia/Eucla'并非所有发行版都默认启用） - 避免在日志或 API 响应中只输出
dt.isoformat()，它不保证含时区缩写；改用dt.strftime('%Y-%m-%d %H:%M:%S%z')或明确序列化为 ISO 8601 带 Z（如dt.astimezone(ZoneInfo('UTC')).isoformat().replace('+00:00', 'Z')）
最易被忽略的一点：时区数据库更新不会自动触发 Python 进程重载。哪怕你更新了系统 tzdata，已启动的 Python 服务仍用旧缓存，必须重启进程才能生效。
