Python datetime 处理夏令时结束的重复小时会报错，如美国东部时间2024-11-03 01:15对应两个UTC时间点，pytz或旧版zoneinfo无法自动区分。
Python datetime 遇到夏令时结束的重复小时会报错
当本地时区在夏令时结束（如北京时间不涉及，但美国东部时间 EST/EDT、欧洲中部时间 CET/CEST 会）时，会出现同一本地时间出现两次的情况。例如美国东部时间 2024-11-03 凌晨1:15，在 EDT → EST 切换时，"2024-11-03 01:15" 对应两个不同的 UTC 时间点。此时用 pytz 或旧版 zoneinfo（Python AmbiguousTimeError。
pytz 中必须显式指定 is_dst 参数
使用 pytz 时，不能直接调用 tz.localize(dt) 解析模糊时间，必须传入 is_dst 明确意图：
-
is_dst=True：表示该时间属于夏令时（即第一次出现的 1:15，仍为 EDT） -
is_dst=False：表示该时间属于标准时间（即第二次出现的 1:15，已切为 EST） -
is_dst=None：触发异常（默认行为），不推荐省略
示例：
import pytz
from datetime import datetime
<p>et = pytz.timezone("US/Eastern")
dt_naive = datetime(2024, 11, 3, 1, 15)</p><h1>✅ 正确：明确选择</h1><p>dt_edt = et.localize(dt_naive, is_dst=True) # UTC-4
dt_est = et.localize(dt_naive, is_dst=False) # UTC-5</p><h1>❌ 错误：不传 is_dst → AmbiguousTimeError</h1><h1>et.localize(dt_naive)</h1><p>Python 3.9+ zoneinfo 默认采用“后一次”（standard time）语义
zoneinfo 的行为与 pytz 不同：它在遇到模糊时间时，默认按 较晚发生的那个偏移量 解析（即认为是标准时间开始后的那次），且不抛异常。这符合 POSIX 和大多数系统调用（如 strftime）的惯例，但容易让人误以为“自动处理了”，其实只是做了隐式选择。
- 对
"2024-11-03 01:15"，zoneinfo默认解析为 EST（UTC-5），即第二次出现 - 无法像
pytz那样通过参数切换；若需第一次（EDT），必须手动加偏移或用fromutc反推 - 注意：
zoneinfo的astimezone在转换回本地时间时，仍可能产生歧义输出，不解决源头问题
真正安全的做法：避免从模糊本地时间构造 datetime
所有基于本地字符串的解析都存在歧义风险。生产环境应优先采用以下方式：
- 接收带 UTC 偏移或时区缩写的输入（如
"2024-11-03T01:15:00-04:00"或"2024-11-03T06:15:00Z"） - 前端提交时间前，用
Intl.DateTimeFormat或date.toISOString()发送 UTC 时间 - 数据库存储统一用
datetime+timezone=UTC，显示时再转换为用户本地时区（此时无歧义） - 若必须解析本地字符串，应要求用户明确选择“夏令时”或“标准时间”，再传给
is_dst或做偏移校正
模糊时间不是格式问题，而是语义缺失——缺的不是代码，是上下文。
