根本原因是cron表达式绑定本地时区，夏令时切换导致小时“消失”或“重复”，使调度失效；正确方案是APScheduler显式传入ZoneInfo实例并统一用UTC存储时间。
夏令时切换时 cron 表达式失效的根本原因
因为 cron 表达式默认绑定系统本地时区，而夏令时切换会直接“删除”或“重复”某个小时，导致调度器无法匹配到原定时间点。
比如美国东部时间每年 3 月第二个周日 2:00 AM 会跳到 3:00 AM —— 那么设为 0 2 * * * 的任务，在那天根本不会触发；11 月第一个周日 2:00 AM 又会重复一次，可能触发两次。
- 系统时区设为
America/New_York时，cron解析的是“本地墙钟时间”，不是 UTC 或固定偏移 -
dbader/schedule库底层仍依赖系统time.time()和本地datetime.now()，未自动做 DST 感知对齐 - APScheduler 的
cron触发器同样受此限制，除非显式指定timezone参数并用ZoneInfo
用 ZoneInfo 替代系统时区配置 APScheduler
APScheduler 支持传入 timezone 参数，但必须是 zoneinfo.ZoneInfo 实例，不能用字符串或 pytz 对象。
错误写法：BackgroundScheduler(timezone='America/New_York')（会静默失败或回退到系统时区）
立即学习“Python免费学习笔记（深入）”；
正确写法需提前安装 tzdata（Windows 必须，Linux/macOS 通常自带）：
pip install tzdata
然后：
from apscheduler.schedulers.background import BackgroundScheduler
from zoneinfo import ZoneInfo
<p>scheduler = BackgroundScheduler(
timezone=ZoneInfo('America/New_York') # ✅ 显式传入 ZoneInfo 实例
)
scheduler.add_job(
func=lambda: print('执行时间:', datetime.now(ZoneInfo('America/New_York'))),
trigger='cron',
hour=2,
minute=0
)- 即使夏令时切换，
ZoneInfo会自动按 IANA 数据库规则映射到正确 UTC 偏移（如 EST → EDT） - 触发逻辑基于“该时区的本地时间语义”，而非系统 clock 的 raw 秒数
- 若不设
timezone，APScheduler 默认用time.tzname，而它在 DST 切换窗口内不可靠
避免用 interval 模式替代 cron 处理固定“本地时间”任务
有人试图用 interval + 时间判断绕过 cron 问题，比如每分钟检查是否到 2:00 —— 这看似灵活，实则埋雷。
典型错误逻辑：
def check_and_run():
now = datetime.now().time() # ❌ naive time，无时区语义
if now.hour == 2 and now.minute == 0:
do_backup()
scheduler.add_job(check_and_run, 'interval', minutes=1)-
datetime.now()返回 naive 对象，跨服务器部署时可能因系统时区不同而误判 - 夏令时切换当天，2:00 根本不存在（跳变）或重复（模糊），
now.time()可能永远取不到该值 - 每分钟轮询浪费资源，且精度依赖 Python 线程调度，易漏触发
- 真正可靠的方案是：用
cron+ 显式ZoneInfo，让调度器自己处理 DST 边界
数据库和日志时间戳必须与调度器时区解耦
定时任务执行时写入数据库或打日志，如果混用本地时间，会放大夏令时混乱。
常见错误链：
- 调度器用
ZoneInfo('Europe/London')在 2:00 触发任务 - 任务内调用
datetime.now()记录日志 → 得到 naive 时间，实际是服务器本地时区（比如 UTC+8） - 数据库字段是
TIMESTAMP WITHOUT TIME ZONE→ 存入后丢失上下文，查询时按错误时区解释
务必统一用 UTC 存储：
# ✅ 正确：所有时间记录都转为 UTC
log_time = datetime.now(ZoneInfo('UTC'))
db_cursor.execute("INSERT INTO logs (ts) VALUES (%s)", (log_time,))
<h1>✅ 调度任务中也用 UTC 做内部计算</h1><p>task_start = datetime.now(ZoneInfo('UTC'))</p><h1>……业务逻辑……</h1><p>task_end = datetime.now(ZoneInfo('UTC'))显示给用户时，再按需转换：task_start.astimezone(ZoneInfo('Europe/London'))。
真正棘手的从来不是“怎么让任务跑起来”，而是“跑的时候，所有环节是否共享同一套时间语义”。哪怕调度器本身没问题，只要日志、DB、API 有一处用 naive 时间或错配时区，夏令时一到，整个时间链就断了。
