Python 中 datetime 比较看似简单，但一不留神就会掉进时区、类型、可变性等隐性陷阱。最常见问题不是代码报错，而是逻辑出错——比如本地时间误当 UTC 比、naive 和 aware 混用、忽略夏令时跳变，结果判断“未来时间已过”或“两秒间隔变成两小时”。
时区感知（aware）与非感知（naive）不能直接比较
这是最常踩的坑：一个带时区的 datetime（如datetime.now(timezone.utc)）和一个不带时区的（如datetime.now()）直接比较会抛TypeError。但更危险的是——在某些旧版本或特定上下文中，它可能“静默成功”，却按字面值错误计算。
- 务必统一时区状态：要么全转成 aware（推荐），要么全转成 naive（仅限本地开发调试）
- 用 datetime.astimezone() 安全转换，不要手动加减固定小时数（避开夏令时风险）
- 新建 aware 对象时，优先用zoneinfo.ZoneInfo（Python 3.9+）或pytz，避免用datetime.replace(tzinfo=…)——后者不处理时区规则，仅硬绑定
字符串解析后默认是 naive，极易引发隐性错误
用 strptime 或dateutil.parser.parse解析 ”2024-05-20 14:30:00″ 这类字符串，默认返回 naive datetime。若你后续拿它跟 UTC 时间比，就等于把本地时间当 UTC 用了。
- 显式指定时区：用parser.parse(“…”, default=datetime.now(timezone.utc))，或解析后立刻astimezone()
- 对 API 返回的时间字符串，先看文档明确时区含义（如 ISO 格式末尾带 ”Z” 表示 UTC，带 ”+08:00″ 需保留）
- 入库或序列化前，强制转为 UTC 并存储为 ISO 字符串（含时区信息），避免歧义
注意 datetime 是不可变对象，比较操作不改变原值
新手有时误以为 dt1 > dt2 会修改 dt1 或 dt2，其实只是返回布尔值。真正容易混淆的是链式比较：a 等价于a，中间的 b 只求值一次——这点本身安全，但若 b 是函数调用（如get_now()），就可能因两次调用返回不同值而破坏逻辑。
立即学习“Python 免费学习笔记（深入）”；
- 链式比较中，避免用有副作用或返回动态值的表达式作中间项
- 跨系统比较时间时，别依赖datetime.utcnow()（已弃用），改用datetime.now(timezone.utc)
- 做“是否过期”判断时，统一用当前 UTC 时间作为基准，而非本地时间，减少部署环境差异影响
警惕夏令时切换窗口内的边界情况
在 DST 开始日（如 3 月某日凌晨 2 点跳到 3 点），存在“不存在的时间”；结束日（如 11 月某日凌晨 2 点回拨），存在“重复的时间”。此时若用 astimezone() 转换，可能得到意外结果（如跳过 1 小时或重复计算）。
- 业务关键时间比较（如定时任务触发、有效期截止），尽量使用 UTC 时间做运算，规避 DST 干扰
- 若必须用本地时区，用 zoneinfo.ZoneInfo 配合 fold 参数明确处理重复时间（Python 3.6+）
- 测试时覆盖 DST 切换前后各 1 小时，验证逻辑是否健壮
