Python 定时任务的时间边界：自然日、UTC 与夏令时重复小时

为什么每天执行一次，仍可能算错一天

日报、签到和增量同步常按自然日划分数据。容易忽略的是：“某时区的一个自然日”和“连续经过 24 小时”并不总相同。本文用 Python 标准库构造可复现的小实验，说明业务日期、查询区间和真实耗时应该怎样分开处理；不涉及云资源部署或付费服务。

一、先确定业务日期，不依赖服务器默认时区

服务器可能使用 UTC，而业务按北京时间结算。不要直接用 datetime.now().date() 作为业务日期，否则凌晨跨日时可能拿错日期。应明确写成 datetime.now(ZoneInfo(“Asia/Shanghai”)).date()。

如果业务定义是“每天早上 6 点处理前一天的数据”，触发时刻和统计窗口是两件事：先在业务时区取今天，再减一个日历日得到目标日期。不要用当前时刻减 24 小时来代替所有业务规则。重跑历史任务时，最好直接传入明确的目标日期，并记录所用时区。

二、用左闭右开窗口，避免边界重复

把一天表示为 [当天零点, 次日零点)。这样恰好落在次日零点的记录只属于下一天，不必拼出 23:59:59.999999，也不会因存储精度变化而漏数据。若数据库存的是 UTC 时间，分别构造两个本地边界，再转成 UTC 查询。

下面的示例要求 Python 3.9 或更高版本。ZoneInfo 依赖系统 IANA 时区数据库；Windows 或精简容器缺少数据时，可安装官方维护的 tzdata 包。

from datetime import datetime, time, timedelta, timezone
from zoneinfo import ZoneInfo


UTC = timezone.utc


def day_window(day, zone):
    start = datetime.combine(day, time.min, tzinfo=zone)
    end = datetime.combine(
        day + timedelta(days=1), time.min, tzinfo=zone
    )
    return start.astimezone(UTC), end.astimezone(UTC)


ny = ZoneInfo("America/New_York")
for day, expected_hours in [
    (datetime(2026, 3, 8).date(), 23),
    (datetime(2026, 11, 1).date(), 25),
    (datetime(2026, 11, 6).date(), 24),
]:
    start, end = day_window(day, ny)
    hours = (end - start).total_seconds() / 3600
    assert hours == expected_hours
    assert start <= start < end
    assert not start <= end < end
    print(day, hours)

实测三个日期依次输出 23.0、25.0、24.0。纽约在春季切换夏令时会跳过一个小时，秋季切换则重复一个小时。因此，若先把零点转换成 UTC 再直接加 24 小时，得到的结束边界不一定是下一个本地零点。

对应的数据库条件应是 event_time >= start_utc AND event_time < end_utc，参数使用数据库驱动支持的带时区类型，或者经过明确约定的 UTC 存储表示。不要把无时区字符串和带时区时间混着比较。

注意：这个函数适合上面给出的纽约和上海等场景，不是任意历史时区规则的完整解决方案。有些地区曾在午夜调整偏移，甚至跳过整个日期。面向全球业务时，必须为不存在或有歧义的本地边界制定拒绝、顺延或选择偏移的策略，并补充针对性测试。仅给 datetime 附上 tzinfo 不等于验证本地时间一定存在。

三、重复的 01:30 不是同一个真实时刻

秋季回拨时，本地 01:30 可能出现两次。fold=0 选择前一次，fold=1 选择后一次。一个反直觉细节是：两个 aware datetime 若持有相同的 tzinfo 对象，直接相减会忽略时区偏移差；计算真实经过的秒数应先转换到 UTC。

a = datetime(2026, 11, 1, 1, 30, tzinfo=ny, fold=0)
b = a.replace(fold=1)


assert (b - a).total_seconds() == 0
assert (
    b.astimezone(UTC) - a.astimezone(UTC)
).total_seconds() == 3600

上述断言已运行通过。这不是两次 01:30 之间没有经过时间，而是相同时区对象下的 datetime 减法遵循本地墙上时间语义。不要拿这一结果直接判断任务超时、订单持续时长或服务等级指标。进程内计算耗时通常还应使用 time.monotonic()，以免系统时钟校准影响结果；它的数值不应作为跨进程持久化的日历时间。

四、上线前至少覆盖哪些测试

建议保留普通日、夏令时跳进日、夏令时回拨日、跨年和精确边界样例。业务日期是日历概念，查询窗口是时间区间，超时是耗时概念，三者不要共用一个“减一天”的表达式。

定时器是否在重复小时触发两次，还取决于调度平台的规则，不能仅凭 ZoneInfo 推断。任务重试应依靠持久化的业务幂等键，例如任务名、业务时区和目标日期的组合，而不是仅靠当前墙上时间。跨机器需要统一约定；若同一天允许不同参数独立执行，也应把会影响结果的参数纳入键中。

官方参考

• Python 官方文档 datetime：日期运算、相同 tzinfo 的减法和 fold 规则
• Python 官方文档 zoneinfo：IANA 时区、fold 与时区数据来源

本文示例在本地 Python 环境执行并通过断言；数据库查询写法用于说明边界条件，未声称验证某个具体数据库或云上部署。