SaaS 定时任务执行时间错误，如何检查时区与地区配置？ | 全球代理
区分 UTC 存储与用户时区展示，覆盖 UTC 日界、夏令时跳过与重复小时、用户改时区三类场景，分别核对执行、到达与展示三段时间。
定时任务“跑错时间”，多数不是调度器坏了，而是时区语义没对齐。先确认任务按 UTC 触发还是按用户所在时区触发，再测三类边界：跨 UTC 日界、夏令时跳过或重复的那一小时、用户中途改时区；最后分别核对执行时间、到达时间和页面展示时间。下面整理一套边界用例和记录表。
先明确任务的时间语义和时区规则
一个任务涉及三个时间：存储时间、触发时间、展示时间。绝对时间戳通常以 UTC 存储；对“当地每天 9 点”这类周期任务，还要保存 IANA 时区标识和明确的夏令时策略。触发按用户时区还是按租户时区，必须在需求里写死；展示则跟随用户当前时区。
这三者没定义清楚，测试就无法判断“9 点执行”指的是哪个 9 点。很多争议到最后不是 bug，而是需求没写。代理 IP 只改变网络出口地区，不改系统时区，两者要分开设。跨地区页面回归是另一条线，不能替代任务调度本身的时区验证。测试地区可参考全球代理 IP 产品页选择；调度预期仍应依据产品设定的时区规则和 IANA 时区数据库确认。
验证 UTC 日界与当地日期的对应关系
UTC 日界是最容易出错的地方。用户在东八区设置“每天 0 点执行”，对应 UTC 前一天 16 点；如果调度器按 UTC 日期归组，这条任务会被算到前一天，表现为“当天没跑”或“跑了两天”。
测试方法：选取不同时区各设一条“每日 0 点”的任务，观察触发日期与展示日期是否符合需求。具体城市和夏令时规则可查IANA 时区数据库，不要把固定 UTC 偏移当成全年不变的地区时区。
验证夏令时跳过和重复小时
夏令时切换日期和规则因地区而异。测试前应按目标时区核对当年的转换规则；IANA 时区数据库提供可查的地区时区资料。春季落在被跳过那一小时里的任务，要么顺延，要么明确跳过；秋季落在重复那一小时的任务，可能执行两次。
这两种行为都要有明确规则，并在测试里验证。没有规则，线上就会出现“某天漏跑”或“某天重复扣款”这类事故。
确认用户改时区后任务归属
用户从东八区改到 UTC-5，已有任务跟谁走？常见两种设计：跟随用户当前时区重新计算，或固定在创建时的时区。两种都可以，但必须一致，且要在界面上说清楚。
测试时要覆盖改时区前后的下一次触发，以及改回原时区后是否恢复原状。
分别核对执行、通知和页面显示时间
执行时间看服务端日志，到达时间看消息或通知记录，展示时间看用户界面。三者不一致时，先判断是哪一段错了，再定位到调度、队列还是格式化。
> 表格中的阈值、用例编号和结果如无测试记录支持，均应视为演示样例；实际验收标准以项目需求、历史基线或团队约定为准。填真实记录时至少补齐 IANA 时区标识、经 IANA 核对的当年转换日期、任务本地计划时间、产品所选策略（跳过或顺延）、预期 UTC、实际 UTC 和任务 ID，否则无法按规则复算。
| 场景 | 输入时区 | 期望执行时间 | 实际执行 | 展示时间 | 判定 |
|---|---|---|---|---|---|
| 每日 0 点 | UTC+8 | 前一日 16:00 UTC | 前一日 16:00 | 当日 00:00 | 通过 |
| 夏令时春季 | Europe/Berlin（如 2026-03-29） | 顺延策略下应为 03:00 CEST = 01:00 UTC | 02:30 CEST 与 03:00 CEST 均未触发 | 03:00 | 异常（顺延未生效） |
| 夏令时秋季 | Europe/Berlin（如 2026-10-25） | 02:30 出现两次，按幂等规则只执行一次 | 02:30 CEST 与 02:30 CET 各执行一次 | 02:30 | 异常（重复执行） |
| 改时区后 | UTC+8 → UTC-5 | 按新时区下一次 | 仍按旧时区 | 新时区 | 异常 |
表格里“期望”一列必须来自需求，不能来自上一次的实际结果，否则错误会被当成基线继承下去。
FAQ
换代理IP 会改变任务执行时区吗？
不会。任务按存储的 UTC 或用户设的时区触发，出口不参与。
夏令时切换当晚没有日志，怎么查？
先确认调度器是跳过还是排队，再对该时区的下一次触发。
两个用户看到的时间不同，正常吗？
正常。展示跟随各自时区，执行时间只有一条。
存 UTC 还要保留原始时区吗？
建议保留。不存的话，用户改过时区后就无法回溯当时的设置。