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 都会被展开。

没有任何上传

在这个页面里解析。