開發者工具 · Crontab 產生器

為什麼 cron 沒有時區欄位：本地時間、CRON_TZ 和 UTC 的容器

2026年1月3日 · 背景

規劃任務時區調度

cron 表達式中沒有時區，因此相同的五個欄位在不同主機上表示不同的時刻。這篇文章解釋了 cron 使用哪個時鐘、CRON_TZ 擴充以及容器更改答案的原因。

當所選區域變更時，相同的欄位會產生不同的預覽時刻

`0 9 * * *` 包含一小時，但沒有位置。在 ToolAcre 中，選擇 UTC 或 Asia/Tokyo 會使五個欄位保持不變，同時變更每個 09:00 候選掛鐘所代表的時刻。因此，當兩個環境解釋不同區域中的相同本地標籤時，報告可能會相隔數小時出現。

面板透過「顯示下一個執行」選擇器使這種依賴關係變得明確。查看計劃時使用目標機器的區域，然後在表達式旁邊記錄該假設。此選擇僅影響瀏覽器預覽；它沒有嵌入到複製的 cron 文字中。

剛好有五個欄位規範，沒有命名時區。 `nextRuns` 接受區域作為單獨的選項，並預設為 JavaScript 看到的主機環境。這種分離證明了區域上下文對於 ToolAcre 模型中的表達式來說是外部的。

工作簿宣告每個守護程式讀取哪個時脈。此儲存庫無法配置或檢查守護程序，因此它無法建立通用行為。它只能建議將預覽區域與目標記錄的解釋相匹配，並獨立驗證已安裝的調度程序。

`CRON_TZ` 未解析。在表達式框中輸入它會失敗，因為它不是五個欄位，並沒有每個欄位控制項儲存指令。該工作簿聲稱一種實作支援它，而其他實作則不需要此處未提供的來源。

如果目標記錄了時區指令，請在那裡配置並測試它。不要期望 ToolAcre 在複製表達式時保留指令。使區域元資料與計劃相鄰，直到審查和部署特定於目標的配置。

`TZ` 賦值同樣超出範圍。瀏覽器使用明確 `timeZone` 選項進行格式化和轉換，而不是 crontab 檔案內的環境行。它無法判斷任務是否改變了另一個系統上的計劃評估、命令輸出或兩者都沒有。

此修正避免了微妙但代價高昂的假設。相似的名稱並不意味著相同的角色。將調度程序區域選擇和進程環境視為單獨的問題，並從目標實現而不是從表達式產生器回答這兩個問題。

容器和雲端鏡像不被路由檢查。不查詢 Docker 套接字、主機時鐘或元資料服務。聲稱它們預設為 UTC 在特定部署中可能是正確的，但不能從讀者瀏覽器中執行的 `Intl.DateTimeFormat` 進行推廣。

透過其記錄的工具和配置捕捉實際的目標區域。然後在 ToolAcre 中選擇相同的 IANA 名稱（如果可用）。瀏覽器區域清單反映了其引擎所知道的內容；它不能證明目標包含相同的區域資料或設定。

保持 `0 9 * * *` 固定，並在 UTC 中預覽一個結果，然後在美國/New_York. 每個清單顯示 09:00 作為掛機時間，但紀元時刻因適用的區域偏移量而異。避免發布一小時的永久換算，因為區域偏移量可能會隨日期而變化。

這些測試透過 UTC 和東京午夜以及倫敦日常工作在向前變化中證明了這一原則。使用正在審核的日期的即時候選人。如果部署將計畫轉換為固定的 UTC 小時，請記錄季節性限制，而不是暗示某個值永遠保留本地 09:00。

ToolAcre 將候選項建置為本機日曆元件，並透過瀏覽器區域資料將其轉換。省略了不存在的春進時間，並在經過測試的過渡期間，普通的每日時間仍然與本地時間相同。這些就是預覽實施事實。

它們不是守護程式或雲端調度程序的執行保證。驗證作業將在其中執行的轉換策略。預覽可以揭示風險並提供預期的時刻，而部署的調度程序則提供對操作是否開始的權威觀察。

如果沒有區域上下文，時間表在操作上是不完整的，即使它的五個欄位在語法上是完整的。 ToolAcre 透過將區域保留在單獨的選擇器中並顯示產生的掛鐘清單來代表這一事實。單獨複製的表達式不能包含選擇。

一起記錄表達式和區域，驗證目標配置並在偏移變更附近重新存取候選者。產生器建立並解釋時間表；它不設定伺服器時鐘、編寫時區指令或承諾執行。該邊界使預覽保持有用，而不會誇大控制。