夏令时结束前检查你的定时自动化

先检查那一个重复小时

美国实行夏令时的地区将在2026年11月1日凌晨两点拨回一点；NIST 已确认该日期。[1] 对每日生成报告或发送提醒的应用，应先检查“每天一次”到底指什么。本文以虚构的纽约门店日报为例，提出换时测试方案，不代表客户案例或已测得的成效。门店人员与开发者应能读懂同一份计划说明，不必依赖某个人记住往年的处理方法。

“通过法案”不等于已经生效

截至2026年10月30日，现行《统一时间法》框架仍适用。15 U.S.C. §260a 规定，实行夏令时的地区从三月第二个星期日凌晨两点开始，到十一月第一个星期日凌晨两点结束；这套日期来自2005年修法，生效日为2007年3月1日。[4] 交通部说明，州可依法不实行夏令时，但不能自行选择全年夏令时。[5]

“通过”的新闻有依据：众议院于2026年7月14日通过 H.R.139《Sunshine Protection Act》，但参议院官方页面所列最新进度是7月16日交付委员会，并非已成为法律。[6][7] 因此，不能把众议院表决日当作新制度生效日，也不能据此宣布今年取消回拨。NIST 当前公告仍明确2026年11月1日凌晨两点回拨一小时。[8] 将来若有新法，还须核对正式成法记录和具体生效条款，再调整自动化计划。

把营业时间与间隔分开

“纽约每天早上八点”与“每隔二十四小时”是不同需求。前者跟随当地钟表，后者跟随经过的时间。让负责人选择其一，记录时区，例如 America/New_York；不要只写“美东时间”。固定 UTC 时刻也不能全年保持同一个当地营业时刻。跨时区团队也要指定业务地点，不能让服务器所在地或员工电脑设置代替业务选择。

核对实际调度器

AWS EventBridge Scheduler 文档说明，秋季回拨不重复触发该次计划；春季不存在的 cron 时刻会跳过，按天设置的 rate 则采用二十四小时。[2] Google Cloud Scheduler 提醒，墙钟时间可能在换时日出现执行异常。[3] 不要把一家产品的行为套用到另一家。若软件隐藏调度实现，要求供应商说明；未确认的行为应列为待核实项。

让一个营业日有一个身份

对于每天一份的日报，建议用“门店＋报告类型＋营业日期”标识任务，原子登记领取状态，再生成内容。两个一点半若都到达，仍检查同一个业务身份。此规则只适用于每日一份的约定；每小时任务需不同身份，不能误删正常工作。跨午夜营业的门店还要明确日结界线，不能默认午夜就是营业日结束。

给日志保留两个坐标

记录计划时刻、实际 UTC 时刻、当地时区与偏移、营业日期、结果和外部回执。纽约当天的两个一点半分别对应05:30与06:30 UTC。界面只显示“01:30”会掩盖区别。AI 可解释异常，但不应猜测哪个时刻才算获准发送。这样才能把“计划何时运行”和“实际何时完成”分开解释。

用无害数据演练

在测试环境覆盖普通日、秋季两次一点半、春季缺失时刻及任务中途失败。加入洛杉矶与不换时的门店时区，按各地规则验证。预先写明预期报告数、所属营业日与发送次数；用模拟收件箱，避免为了验收而真的联系客户。测试时钟转换正确，只证明一个环节，不能代替实际调度与投递链路的验证。

补跑前先核对结果

漏跑时先查业务记录与发送回执，再决定补跑、跳过或人工处理。已生成但未发送，与已发送但回执丢失，应走不同路径。登记补跑原因及负责人，沿用原业务身份；不能把仪表盘变绿当作客户已收到的证据。无法证实投递时，应明确显示不确定状态，而不是让自动重发扩大问题。

交付一张可执行清单

本周先挑一个重要计划，写清时区、营业日期规则、重复或缺失时刻处理、补跑负责人和完成证据。换时后按这张清单核对一次。重点是让团队说清“何时该做、是否做完”，而不是只确认服务器时钟已经自动更新。保留这次演练数据；下次换时、调度服务迁移或配置变更后，再运行相同测试。