pytz.localize() 是处理“不存在时间”的唯一安全入口；它自动判断夏令时状态并严格校验，如2025-03-09 02:15在America/New_York时区会抛NonExistentTimeError，避免静默错误。
pytz.localize() 是处理“不存在时间”的唯一安全入口
2025年3月9日美国东部时间凌晨2:00一过，时钟直接跳到3:00——这意味着 2025-03-09 02:15:00 这个本地时间在 America/New_York 时区根本不存在。如果你用 datetime(2025, 3, 9, 2, 15, tzinfo=ny_tz) 强行构造，Python 不报错，但返回的是一个逻辑错误的、偏移量错误的 datetime 对象（比如它可能误标为 EST 而非 EDT，或反之）。
正确做法只有一条：必须通过时区对象的 localize() 方法注入本地时间：
import pytz
from datetime import datetime
<p>ny_tz = pytz.timezone('America/New_York')</p><h1>✅ 正确：localize 自动判断 DST 状态，拒绝非法时间</h1><p>try:
dt = ny_tz.localize(datetime(2025, 3, 9, 2, 15))
except pytz.exceptions.NonExistentTimeError as e:
print(f"该时间不存在：{e}") # 输出：NonExistentTimeError: 2025-03-09 02:15:00 does not exist</p><h1>✅ 或者明确告诉 localize 如何处理（跳过/回退）</h1><p>dt_skip = ny_tz.localize(datetime(2025, 3, 9, 2, 15), is_dst=False) # 强制按标准时间算（不推荐）
dt_aware = ny_tz.localize(datetime(2025, 3, 9, 3, 15)) # ✅ 存在的时间，正常返回-
localize()是 pytz 的核心防护机制，绕过它等于放弃夏令时校验 -
is_dst=None（默认）会严格抛异常；is_dst=True/False可强制指定，但极易引入业务逻辑错误 - 切勿对已有时区感知对象再次调用
localize()，会报AmbiguousTimeError
zoneinfo 中的 fold 参数：Python 3.6+ 的现代替代方案
Python 3.6+ 内置的 zoneinfo 模块用 fold 参数显式表达“模糊时间”（如夏令时结束时的重复小时），但它**不解决“不存在时间”问题**——遇到跳跃仍会静默出错或行为未定义。所以对 2025-03-09 02:15 这类输入，zoneinfo 同样需要前置校验。
实际操作中，应先用 datetime 构造 naive 时间，再用 zoneinfo.ZoneInfo 绑定时区，并依赖 astimezone() 或 fromisoformat() 的解析能力（它们内部会做基础合法性检查）：
from zoneinfo import ZoneInfo
from datetime import datetime
<p>ny = ZoneInfo("America/New_York")
naive = datetime(2025, 3, 9, 2, 15)</p><h1>❌ 错误：直接替换 tzinfo 不触发校验</h1><h1>dt_bad = naive.replace(tzinfo=ny)</h1><h1>✅ 推荐：用 astimezone 转换（需先有参考时区）或用 fromisoformat 解析 ISO 字符串</h1><h1>更稳妥的方式是捕获异常并引导用户修正输入-
fold仅用于处理“重复时间”（如 2025-11-02 01:30 在纽约出现两次），和“不存在时间”是两类问题 -
zoneinfo对不存在时间的处理不如pytz.localize()明确，建议仍用pytz做输入校验，再转成zoneinfo使用 - Python 3.9+ 支持
datetime.fromisoformat()解析带时区的字符串，但对本地时间字符串（无 offset）仍无法自动识别 DST 跳跃
time.mktime() 是夏令时陷阱的放大器，务必避开
time.mktime() 接收本地时间元组，内部依赖系统 C 库的 mktime() 实现——它会对“不存在时间”做**静默修正**：比如把 (2025, 3, 9, 2, 15, 0, ...) 自动当成 3:15 处理，且不报任何提示。这种“自动容错”在日志分析、定时任务调度等场景下会导致时间偏移一小时，极难排查。
- 永远不要用
time.mktime()处理含夏令时风险的本地时间 - 替代方案：先用
pytz.localize()得到 aware datetime，再调用timestamp()方法（Python 3.3+） -
datetime.timestamp()是安全的，它基于 UTC 时间计算，完全规避了本地夏令时歧义
真实项目中的防御性写法
在 Web API 或数据导入场景中，用户提交的“本地时间字符串”必须经过显式校验。不能假设输入合法，也不能依赖库自动兜底。
# 示例：接收用户传入的 "2025-03-09T02:15:00" 和时区名
from datetime import datetime
import pytz
<p>def parse_local_time(date_str: str, tz_name: str) -> datetime:
naive = datetime.fromisoformat(date_str)
tz = pytz.timezone(tz_name)
try:
return tz.localize(naive)
except pytz.exceptions.NonExistentTimeError:
raise ValueError(f"时间 {date_str} 在时区 {tz_name} 中不存在（夏令时跳跃）")
except pytz.exceptions.AmbiguousTimeError:
raise ValueError(f"时间 {date_str} 在时区 {tz_name} 中模糊（夏令时重叠）")</p><h1>调用</h1><p>dt = parse_local_time("2025-03-09T02:15:00", "America/New_York") # 抛 ValueError夏令时不是边缘情况——它是全球半数以上地区每年两次的确定性事件。所有涉及本地时间构造的代码，都必须把“不存在时间”当作一类明确的业务错误来处理，而不是靠调试时偶然发现。
