夏令時結束前檢查你的定時自動化

先檢查那一個重複小時

美國實行夏令時的地區將在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 可解釋異常，但不應猜測哪個時刻才算獲准傳送。這樣才能把“計畫何時執行”和“實際何時完成”分開解釋。

用無害資料演練

在測試環境覆蓋普通日、秋季兩次一點半、春季缺失時刻及任務中途失敗。加入洛杉磯與不換時的門店時區，按各地規則驗證。預先寫明預期報告數、所屬營業日與傳送次數；用模擬收件箱，避免為了驗收而真的聯絡客戶。測試時鐘轉換正確，只證明一個環節，不能代替實際排程與投遞鏈路的驗證。

補跑前先核對結果

漏跑時先查業務記錄與傳送回執，再決定補跑、跳過或人工處理。已生成但未傳送，與已傳送但回執丟失，應走不同路徑。登記補跑原因及負責人，沿用原業務身分；不能把儀表盤變綠當作客戶已收到的證據。無法證實投遞時，應明確顯示不確定狀態，而不是讓自動重發擴大問題。

交付一張可執行清單

本週先挑一個重要計畫，寫清時區、營業日期規則、重複或缺失時刻處理、補跑負責人和完成證據。換時後按這張清單核對一次。重點是讓團隊說清“何時該做、是否做完”，而不是只確認伺服器時鐘已經自動更新。保留這次演練資料；下次換時、排程服務遷移或設定變更後，再執行相同測試。