開發者工具 · Crontab 產生器

Cron 與夏令時間：為什麼 02:30 作業可以跳過或執行兩次

2026年9月4日 · 為什麼它很重要

規劃任務時區夏令時

掛鐘每年跳動兩次，並安排在間隙或重疊中的 cron 作業會出現意外行為。這篇文章解釋了 Vixie 派生的 cron 做了什麼、其他人做了什麼，以及如何圍繞它進行調度。

當所選區域沒有此類掛鐘時間時，可能會出現預覽候選缺失的情況

當所選時區將其時脈向前移動時，每日掛鐘時間可能會在某個日期缺失。 ToolAcre 表示這種情況，對於不存在的本地分鐘不返回任何時刻，並在下次執行清單中跳過它。該表達式仍然有效；一個候選日曆根本無法轉換為該區域中的真實時刻。

此行為在 `wallClockToEpoch` 中實現，它轉換建議的本地日期和時間，將結果格式化回同一區域並比較每個組件。不符合傳回 null。 `nextRuns` 忽略空候選並繼續搜索，防止偽造的附近時間看起來與時間表完全匹配。

時脈變化創造了兩種概念情況：與永遠不會發生的牆時間的前向間隙，以及某些標籤多次出現的後向重疊。該存儲庫進行了測試，用於在向前更改期間維持每日本地時間以及忽略不存在的春季時間。它不包含完整的重疊策略測試套件。

此證據邊界很重要，因為調度程序實作可以做出不同的選擇。本文描述的是瀏覽器預覽演演算法，而不是通用守護程式行為。在時鐘轉換期間依賴重複任務之前，請閱讀並測試目標主機上的實際調度程序，而不是將預覽提升為執行承諾。

此工作簿聲稱特定的 Vixie 派生守護程式在跳轉後執行跳過的作業並抑制重複項。 ToolAcre 在其預覽程式碼中兩者都沒有：它省略了本機元件無法往返的候選者。沒有呼叫守護程式包，也沒有對追趕策略進行建模。因此，這些操作宣告被糾正而不是重複。

測試的倫敦範例在 3 月 2026 變更前後搜尋 01:30。由於轉換日期不存在該本地分鐘，因此傳回的天數為以下有效日期。這證明了路由自身的列表行為。它沒有確定單獨安裝的 cron 進程對已儲存的行執行的操作。

解析器將星星擴展為每個允許的值，但後來的掛鐘轉換仍然決定特定日期時間是否對應到某個時刻。 ToolAcre 沒有針對「通配符作業」的單獨外部守護程序規則。所有候選人都使用相同的日曆搜尋和區域轉換代碼。

描述保持純粹的語法：`* * * * *` 讀作每分鐘，而步進分鐘欄位接收步進措辭。這句話沒有敘述過渡政策。使用該工具的計算範例的下次執行列表，並不要僅從散文中推斷出追趕、重試或重複抑制保證。

區域實作依賴瀏覽器或 Node 執行階段所公開的 `Intl.DateTimeFormat` 資料。 ToolAcre 驗證提供的 IANA 區域名稱，提供引擎的支援清單（如果可用）並包含 UTC。它不會檢查 BusyBox、容器編排器或雲端 cron 產品。

當另一個調度程序不同意時，將其視為方言和執行時問題。記錄其版本、區域配置和觀察到的轉換行為。瀏覽器預覽作為透明比較仍然有用，但其程式碼無法回答另一個服務應用哪個策略或該服務是否重試錯過的工作。

更安全的工作方法是選擇部署區域，輸入建議的日常表達並檢查該環境已知的下一次轉換的日期。如果所需的候選人缺席，請選擇目標明確記錄的另一個掛機時間或排程程序策略。更改時間後重新執行預覽。

來源在 02:30 處包含預設，但預設只是範例，並非一般建議。其有效性取決於所選的日曆和區域。 ToolAcre 的五個結果視窗可能不會跨越遙遠的過渡，因此在審核實施行為時在測試中選擇合適的起始上下文。

與工作簿的分離不同，區域處理直接是該工具預覽的一部分。該面板詢問“顯示下一個執行區域”，並警告執行 cron 的機器可能使用與讀取器不同的區域。選擇區域會變更產生的時刻，同時保留表達式的掛鐘欄位。

此選擇僅配置瀏覽器計算。它不會編寫時區指令、更新伺服器或將選擇嵌入到複製的表達式中。在相鄰的部署檔案中保留預期區域，然後透過經過驗證的針對該環境的機製配置實際的調度程序。

下次執行清單是來自五個欄位的模型輸出：起始時刻、日曆算術和瀏覽器區域資料。它對於檢測不存在的時間和意外的時間變化非常有價值。它既不保留守護進程跟踪，也不保留命令執行的證據。

使用預覽來識別有風險的牆時間，然後驗證過渡邊界處的目標調度程序。 ToolAcre 的承諾是狹隘的：當地選定的時間存在時，日常工作將保留在該時間，並忽略不存在的當地候選人。除此之外的一切都屬於已部署的系統。