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用了。

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

• 显式指定时区：用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小时，验证逻辑是否健壮