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
ny_tz = pytz.timezone('America/New_York')
✅ 正确：localize 自动判断 DST 状态，拒绝非法时间
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
✅ 或者明确告诉 localize 如何处理（跳过/回退）
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() 的解析能力（它们内部会做基础合法性检查）：

绘蛙AI商品图

电商场景的AI创作平台，无需高薪聘请商拍和文案团队，使用绘蛙即可低成本、批量创作优质的商拍图、种草文案

下载

from zoneinfo import ZoneInfo
from datetime import datetime
ny = ZoneInfo("America/New_York")
naive = datetime(2025, 3, 9, 2, 15)
❌ 错误：直接替换 tzinfo 不触发校验
dt_bad = naive.replace(tzinfo=ny)
✅ 推荐：用 astimezone 转换（需先有参考时区）或用 fromisoformat 解析 ISO 字符串
更稳妥的方式是捕获异常并引导用户修正输入

• 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
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} 中模糊（夏令时重叠）")
调用
dt = parse_local_time("2025-03-09T02:15:00", "America/New_York")  # 抛 ValueError

夏令时不是边缘情况——它是全球半数以上地区每年两次的确定性事件。所有涉及本地时间构造的代码，都必须把“不存在时间”当作一类明确的业务错误来处理，而不是靠调试时偶然发现。