Cron 運算式

重點是「接下來會在什麼時候跑」

一張速查表能告訴你那五個欄位的意思，但它沒辦法告訴你：你的運算式在明年三月會落在一個根本不 存在的時間上，或者它實際執行的次數是你想的四倍。

所以這一頁會顯示接下來真正的執行時間，在指定的時區下計算，並在日光節約時間吃掉某次執行時 明講。

大家都會搞錯的那條規則

「日」和「星期」兩個欄位是 OR，不是 AND——但只有在兩者都有限制時才是。

0 0 1 * MON 不是「每月一號，而且那天是星期一時才跑」。它的意思是每月一號會跑，而且每個 星期一也會跑。以一般的月份來說那是五、六次，不是一次。

如果兩個欄位只有一個有限制，那就單純由那一個決定——這正是為什麼這條規則能讓人幾年都沒發現。 只要你的運算式落在這條規則會生效的情況，這一頁就會明確告訴你。

這個行為之所以寫進 POSIX，是因為 Vixie cron 當年就是這樣做的，之後每一個主流 cron 都照抄了。

日光節約時間

這是各種說明文章出錯的地方，而且它不是罕見的邊界情況——每年會發生兩次，而且會影響每一個排在 午夜到凌晨三點之間的排程。

**春季往前撥。**一個把 02:00 直接跳到 03:00 的時區，那一天根本沒有 02:30。寫著 30 2 * * * 的運算式就是不會執行。不是晚跑、也不是早跑，而是被跳過。這一頁會把那些日期列出來， 而不是顯示一個從未發生過的時間。

**秋季往後撥。**那一個小時會重複，所以 01:30 會出現兩次。各家 cron 對「該跑一次還是兩次」的 做法並不一致；這裡顯示的是第一次，而知道你的排程器可能不一樣是有價值的。

安全的做法：把絕對不能漏掉的工作排在 01:00–03:00 以外，或者直接用 UTC 執行，那裡不會發生 這件事。

欄位，以及那些會絆倒人的地方

┌───── 分  0-59
│ ┌─── 時  0-23
│ │ ┌─ 日  1-31
│ │ │ ┌ 月  1-12 或 JAN-DEC
│ │ │ │ ┌ 星期 0-6 或 SUN-SAT
* * * * *

• **0 和 7 都是星期日。**每個 cron 都接受這兩種寫法，而且在有人被搞混之前，沒有任何文件會 提到這件事。
• */15 是「從 0 開始每 15」，也就是 0,15,30,45——不是「從現在起每 15 分鐘」。
• 5/15 是「從 5 開始往後」，也就是 5,20,35,50。
• **六個欄位是另一種方言。**Quartz 和某些排程器會把「秒」放在最前面。把它當成五欄位來讀，會讓 每個欄位都位移一格，產生一個看起來合理但其實是錯的排程——所以這裡會指名拒絕，而不是硬猜。
• @daily、@hourly、@weekly、@monthly、@yearly 都會被展開。

沒有任何上傳

在這個頁面裡解析。