Command Palette

Search for a command to run...

Cron 表达式解析器:将任何时间表解码为纯英语

Cron 表达式解析器:将任何时间表解码为纯英语

T
Toolz Team
|Jul 12, 2026|22 最小读数

时间和日期 合集的一部分

我写过的最昂贵的 cron 表达方式是 0 0 * * 0。它运行每周摘要电子邮件我正在建设的Laravel SaaS,我绝对确定这意味着"周最后一天的午夜。"这意味着午夜星期天。我的心理模型说,星期六结束的星期五周,客户得到了他们的"周在评论"电子邮件晚了一天,团队中没有人抓住它,因为团队中也没有人能读到cron - 我们都只是眯着眼睛看五块田地,点点头。

That's cron语法的肮脏秘密:几乎每个写它的人都是与他们半记得的先前表达式进行模式匹配的格式已有四十多年的历史,足够密集,以至于单个字符完全更改日程安排,它默默地失败了's没有"的编译器错误运行在错误的一天。"工作只是在错误的一天运行,永远,直到有人注意到。

cron 表达式解析器 closes that gap。你粘贴表达式,它用通俗的英语告诉你实际会发生什么- 0 0 * * 0 00:00 回来,在周日"-加上下一次运行何时会启动。那个回读步骤是发送时间表和发送猜测之间的区别。我在toolz。dev上构建了那个,因为我厌倦了上下文切换到终端,而且因为我在WP中处理了多年的wp-cron混乱管理告诉我,调度错误是软件中最耐心的错误。

本指南涵盖了如何使用解析器、五个字段的实际工作原理(包括导致大多数生产事件的两个怪癖)以及 cron 语法的不同之处 克朗塔布、GitHub Actions、Quartz 和 Laravel。

TL;博士: 将任何 crontab 表达粘贴到 Toolz.dev Cron 解析器 and get一个纯英文翻译加上即将到来的运行时间- 立即,客户端,无注册 在你部署日程安排之前,总是验证两件事:周日编号(0和7都是周日)和调度程序运行的时区(GitHub Actions总是UTC)。将其与 时间戳转换器 当您需要跨区域翻译下一次运行时间时,以及 日期差计算器 到理智检查间隔。


主要特点

纯英文翻译

解析器的核心工作正在转变 */15 9-17 * * 1-5 into "每过15分钟一小时9,10,11,12,13,14,15,16,17,在星期一,星期二,星期三,星期四,星期五。" It's 冗长 - 它枚举而不是崩溃"9 到17"回到一个范围 - 而且那个冗长是点。枚举是明确的;一个总结范围是另一个机会误读。这句话是你可以粘贴到拉请求描述,在立体声中朗读,或显示非技术利益相关者。raw表达式不是。根据我的经验,代码审查期间翻译最重要:一个审查者谁会橡皮图章五个神秘的字段将立即抓住"等等,为什么小时17出现工作应该停止在下午5点?"当每个小时被拼写出来。翻译使时间表可伪造,这正是raw cron语法失败的地方。

下一次运行预览

知道什么是一种表达 手段 是问题的一半;知道什么时候 接下来开火 is 另一半。解析器计算接下来的五次执行,这样你就可以违背你的意图去观察它们。这就是微妙错误浮出水面的地方- 这个表达式用英语读起来很好,但在27天内产生下一次运行的""因为你把月中的某一天和某个月混淆了,或者是当你在周末之后的03:00时在今晚03:00开火的。我现在每次都检查下一次运行列表,即使对于表达式I'm有信心。特别是对于表达式I'm有信心-看到开场轶事。

关于如何计算这些时间的两个细节。首先,他们're 评估了 您的浏览器's本地时区的, 不是UTC 而不是你的服务器's区域-每次运行显示两次,一次作为本地时间戳,一次作为等效的UTC即时,因此您可以读取与部署目标匹配的二,当月日和周日都受到限制时,解析器应用real cron's OR语义而不是AND: 0 0 1 * 1 1月1日火灾 每周一,不仅是 1 日星期一。那条规则绊倒了有经验的人,看到五个具体的日期,在某种程度上让这句话变得显而易见。

一个粗糙的边缘:一种不可能的表达方式 0 0 30 2 * (2月30日)解析为有效,愉快地将自己描述为"在00:00,在30个月的某一天,在2月,"然后显示一个空的下一轮列表。空意味着永远不会。它's正确,但它's安静 - a "这个时间表永远不会开火"警告是明显的改进,我还没有't建造它。

逐场细分

器(parser)将表达式拆分为五个组件- 分,小时,月份的一天,月份,星期的一天- 并显示每个组件的贡献。这很重要,因为 cron 错误几乎总是单字段问题:错误列中的正确值。 0 12 * * * (每日中午)和 12 0 * * * (每天上午12:12...不,每天00:12)是相隔一个交换看到"小时:0"明确标记是你如何在两秒而不是两周内抓住那个交换。

支持范围、步骤和列表

Real-world 表达式非常依赖于运算符语法: 1-5 范围, */10 步骤, 1,15 列表和组合类似 0 8-18/2 * * 1,3,5。解析器处理所有它,包括使人类读者绊倒的组合形式。范围上的步进值 - 8-18/2 义"从8到18"每2小时-是合法的,有用的,而且没有工具几乎无法读取如果你'曾经从一个已离开的系统管理员那里继承了一个充满这些的crontab,你知道为什么存在这个功能。

严格的五场验证(包括它赢得的't接受)

解析器采用标准的五字段表达式,不采用其他任何内容。粘贴 @daily 并且您会收到错误 - "预期 5 个字段(每月每分钟小时,每周每分钟),得到 1 " - 不是翻译。相同为 @hourly@weekly、和 @reboot。那's是真正的差距而不是设计原则,而I'宁愿这么说,也不让你在调试中发现;速记宏在真正的crontab中很常见,它们属于工具中,直到它们're in,手动翻译: @hourly0 * * * *@daily0 0 * * *@weekly0 0 * * 0@monthly0 0 1 * *@yearly0 0 1 1 *@reboot 根本没有五场等效的 - 它是'时间表,它在守护程序启动时运行一次,这一事实让很多从 crontab 运行迁移的人感到惊讶。

严格在其他地方得到了回报。六场石英表达式被拒绝,带有场计数,而不是被默默地误读。超出范围的值命名了字段和法定范围(Value 25 out of range for hour (allowed 0-23))。反向范围如 5-1 ares catch。而且它接受真正的海盗所包含的东西: 月和日名称(JANSUN), 7 作为周日和 Vixie 的第二个拼写 5/15 form 含义 "从5"开始的每15个。值得知道,而你'手翻译那些宏:每 @daily job on a server 在同一瞬间开火 - 午夜 - 所以其中四十个是夜间负载尖峰。我将我的分散在奇数分钟(17 3 * * *43 4 * * *)正是出于这个原因。

客户端处理

Parser 完全在你的浏览器中运行 你粘贴的任何东西都不会上传、记录或存储 这听起来像是样板隐私语言 直到你记住 crontabs 实际上包含什么:你的备份时间表,你的计费运行时间,你的安全扫描开火的确切分钟 基础设施调度是侦察数据,它与其他人保持距离's 服务器是't 偏执狂;it's 只是没有创建一个不需要存在的问题。


如何使用 Cron 解析器

第 1 步:粘贴或输入您的表达方式

打开 克朗解析器 并删除表达式 - 来自 crontab 文件,a schedule: github Actions 工作流程、Kubernetes CronJob 清单或 Laravel 中的块 ->cron() call。标准五字段语法按原样工作; @daily and its siblings don't,所以先把那些扩充到五个字段。然后打Parse。if you're 从头开始而不是解码,预设的按钮(每分钟,小时,每日午夜,工作日上午9点,每月1日)加载一个工作表达式,你可以逐字修改,随走随重新解析。

第 2 步:阅读翻译返回

这是人们跳过并应该的步骤't。阅读纯英文输出并将其与头脑中的句子进行比较。如果您写了表达意图"每周一上午 9 点",回读说"每月 1 日 09:00" - 恭喜你,你刚刚在制作完成之前抓住了经典的列交换。回读是你的单位测试。

第 3 步:验证下一次运行时间

5次即将执行死刑 检查日期是否落在你预期的地方今晚、明天还是下个月第一次运行注意运行之间的差距-错位 */ 步转动"每6小时"进入"每6小时每分钟" (* */6 * * * vs。 0 */6 * * *),而相隔一分钟而不是相隔六个小时的五次跑步是很难错过的,空名单意味着赛程永远无法开火。

4步:部署前对时区进行核算

解析器告诉您 相对于时钟;您的调度程序决定 clock。部署之前,确认执行系统使用什么时区。github 操作:始终为 UTC,无例外。服务器:无论操作系统设置为什么,经常在云盒上使用 UTC。Laravel:您的应用程序时区,除非您链接 ->timezone()。翻译下一个运行时间 时间戳转换器 如果您需要在本地区域或客户处查看它's。


技术深度潜水:Cron 表达方式的实际工作原理

五字段格式来自 Unix cron,由 Paul Vixie's cron 在 20 世纪 80 年代末实现 - 记录在案 crontab(5) and still shiping, in dependerful form, on most Linux systems todays。the fields, left to right:

允许值 注释
分钟 0.59
小时 0 23 24小时制,0为午夜
月日 1,31 谨防没有 31 号的月份
1,12 或 JANmidec Vixie cron 中允许使用的名称
一周中的某一天 0.7 或 SUN 绝地求生 0和7都是星期日

每个字段都接受 * (任何值),列表 (1,15),范围(1-5),以及步骤(*/1020-59/5)。that's整个语法。复杂度是't在语法中-it's在三个行为怪癖中。

怪癖一:周中零。 佩尔 crontab(5),0和7都表示星期日。一些较旧或更严格的实现只接受0。quartz - Jenkins和一半的企业软件使用的Java调度程序 - 从第1天开始编号第1天,7 周日,所以石英's 2 是星期一,而crontab's 2 is 星期二。如果你曾经在系统之间迁移日程, 这个离一的就是在等待。总是解析, 永远不要转录。

怪癖二:每月一天或每周一天。 Here's 几乎没人知道的,直到咬到他们。当 两者 月日和周日字段受到限制(两者都不受限制) *),Vixie cron 负责这项工作 要么 匹配 - OR,而不是 AND。所以 0 0 13 * 5 dones't表示"13日星期五。"它表示"每月13日和每周五。"这是记录在案的行为 crontab(5) 且深深地违背了直觉,如果你真的需要"13号星期五,"你需要一个脚本端的日期检查或者一个语法更丰富的调度程序。

怪癖三:时区和夏令时。 Cron 没有时区字段,表达式在调度程序's 当地时间中解释,不管那是什么 两个具体后果:

  • GitHub 操作运行 schedule: UTC 中的触发器,完全停止。 安排的工作流程 0 9 * * * 9点(UTC)起火 - 根据季节的不同,纽约凌晨4点或5点,因为UTC不't观察DST但你的目标受众's时钟确实如此。你的"9点每日报告"每年两次漂移一个小时,除非你调整工作流程或用代码处理它。
  • DST观测区的服务器上,一年一晚02:00 03:00小时不存在't存在,一晚发生两次。 02:30安排的工作要么跳过,要么根据实现情况双开,无聊的,正确的修复:在01:00和03:00本地外安排关键工作,或者在UTC上运行服务器,我两者都做。

扩展格式。 Quartz 使用六到七个字段(领先秒字段和可选的尾随年份),以及额外的运算符 L (最后一个), W (最近的工作日),以及 # (月的第n个工作日)。有些crons也支持领先的秒字段。如果你的表达式有六个字段,而你'不确定它是哪一种方言,将其粘贴到解析器中- 一个被解释为五字段的六字段表达式会产生明显错误的输出,这本身就是诊断和 @reboot的,特殊字符串的奇怪鸭子,是't一个时间表:它在守护程序启动时运行一次,在现代系统上意味着"每当框重新启动时,"这一事实让许多从crontab运行数据库迁移的人感到惊讶。

为了更广泛地了解与调度工作相结合的开发人员实用程序, 编码工具指南 覆盖整个工具箱。


常见用例

调试 Laravel 调度程序条目

Laravel's调度程序用流畅的方法包裹cron - ->dailyAt('03:00')->weeklyOn(1, '8:00')- 但逃生舱口, ->cron('*/5 * * * 1-5'),是原始的crontab语法,复杂的日程最终就在那里,系统crontab运行 schedule:run every minute,而拉拉维尔在内部决定什么's到期当一个预定的命令是't开火时,我的第一步是粘贴 ->cron() string 进入解析器确认它意味着上面评论声称的意思,大约一半的时间,它没有't。另一半,bug是时区:app设置为 UTC 而开发人员假设当地时间。解析器在几秒钟内解决第一个情况,并用手指指向第二个。

在 WordPress 网站上解开 wp-cron

WordPress 附带 wp-cron,这根本就是't cron - it's 一个伪调度程序,在页面访问中背负,因此一个低流量网站's"每小时"工作可能每四个小时运行一次,一个高流量网站对每个请求支付少量税。在我的 WP 管理年份中,这产生了源源不断的"预定帖子aren't发布"报告。标准修复是禁用 wp-cron (DISABLE_WP_CRON)和触发 wp-cron.php 来自真实的服务器 crontab - 此时您'通常会重新编写实际的 cron 表达式 */5 * * * *并且解析器不断验证它们。如果您以任何规模运行 WordPress,则本周(而不是有一天)值得进行此迁移。

验证 GitHub 操作时间表

CI调度悄然失败:一个停止运行的夜间构建dos't页面anyone。a时 schedule: trigger,我解析表达式,看下一次运行时间,然后在心理上加上utc偏移量,具体到actions的两个额外细节:日程安排只在默认分支上运行,运行可以在高负载时段延迟或掉落 - GitHub's 自己的docs这样说,如果确切的时机很重要,cron触发的Actions是错误的工具;如果近似时机没问题,至少让近似时间为 大约时间。

审计继承的 Crontab

1个长寿的服务器,都积累了1个不再在那里工作的人写的crontab。运行 crontab -l 通过解析器粘贴每一行是我所知道的最快的审核:十分钟内您就有了一个简单的英语时间表库存,并且您几乎总是会发现至少一项工作正在做一些没人记得的事情 - 备份运行两次,清理脚本从未与它应该匹配的那一天,a * * * * * 应该如此 0 * * * * 每小时锤击 API 六十次。当在迁移过程中将旧的 crontab 与新的 crontab 进行比较时, 文本差异工具 除了解析器之外,评论也是机械的。

安排 Kubernetes CronJobs

K8s CronJobs 使用标准的五字段语法,并且自 1.27 起支持显式 timeZone field - 相对于经典 cron 的真正改进。解析器工作流程相同:验证表达式,检查下一次运行,然后确认 startingDeadlineSecondsconcurrencyPolicy cron本身没有的故障模式覆盖't。表达式可以是完美的,如果慢速运行与下一个触发重叠,工作仍然堆积起来;解析器正确获取时间表,因此您可以将注意力花在这些操作设置上。


克朗方言比较

维克西·克朗/克朗塔布 GitHub 操作 石英 拉拉维尔调度程序 系统定时器
字段 5锛屽湪娴欐睙鏉 5锛屽湪娴欐睙鏉 6 和 7(第二年) 5(经由过程) ->cron()) OnCalendar 语法,不是cron
周日编号 0 和 7(0 和 7 = 太阳) 0 和 6 (0 = 太阳) 1,7 (1 = 太阳) 关注 crontab 名字(MonTue)
时区 系统本地 始终 UTC 可配置 App 时区或 ->timezone() 系统本地或 Timezone=
特殊字符串 @daily@reboot等等。 不支持 不支持 而是流畅的方法 OnBootSec=,日历速记
秒精度 否(最小 ~ 5 分钟实用) 是的 否(每分钟滴答) 是的
最好的 服务器作业 CI/CD 时间表 JVM 生态系统 拉拉维尔应用程序 现代 Linux 服务

When to 使用 which:crontab 用于普通服务器作业,当您想要在现代 Linux 上免费记录和依赖处理时使用 systemd 定时器,当作业无论如何都生活在您的应用程序内部时使用框架调度程序,以及仅为 CI 任务调度操作,这些任务可以容忍模糊定时。无论您选择哪个,五字段表达式都是通用语言 - 这就是为什么能流利地说它的解析器属于您其他内容旁边的书签 web开发人员工具包


常问问题

什么是 cron 表达式解析器?

cron 表达式解析器是一种读取 crontab 语法的工具 */15 9-17 * * 1-5- 并将其翻译成简单的英文时间表描述,通常与下一个执行时间的预览一起。它可以让您在部署时间表之前验证时间表的实际操作,而不是在工作在生产中错误时间启动时发现误读字段。

cron 表达式中的五个字段是什么意思?

从左到右:分钟(0 点 59 分)、小时(0 点 23 分)、月份日(1 点 31 分)、月份(1 点 12 分)和周日(0 点 7 分,其中 0 点和 7 点均指周日)。每个字段接受 * 对于任何值,逗号列表、连字符范围和 / 步值。所以 30 2 1 * * 意思是每月第一天 02:30。

为什么我的亲信工作时间不对?

2个最常见的原因是时区和字段混乱,Cron在调度程序中运行's本地时间- GitHub Actions总是使用UTC,许多云服务器也这样做- 所以安排在"9 AM"的工作可能会从挂钟中关闭几个小时另一个经典是交换字段,比如将小时值放在分钟列中解析表达式并检查下一次运行时间,这两者都会捕获。

0和7都是星期天在cron吗?

在 Vixie cron 和大多数 Linux 实现中,是的 - crontab(5) man page 允许周日同时使用 0 和 7。但这并不通用:石英从周日开始对第 1 代 7 进行编号,一些严格的解析器拒绝 7。在系统之间移动表达式时,重新验证周日字段,而不是假设编号继续。

什么 0 0 13 * 5 其实可以吗?

Not "13日星期五。"当月日和周日都受到限制时,标准cron将他们视为OR:该工作每月13日进行一次 on every Friday。这是记录的Vixie cron行为,也是格式's最被误解的规则之一。如果您需要一个真正的AND,请在脚本本身内部添加日期检查。

夏令时如何影响亲信工作?

DST 观察时区的服务器上,在本地时间 01:00 到 03:00 之间安排的作业可以跳过一次运行(当时钟向前跳转时)或运行两次(当它们向后退回时),这取决于实现的最安全模式是在 UTC 上运行服务器或在该窗口之外调度关键作业。请注意,像 GitHub Actions 这样的基于 UTC 的调度程序 don't 跳过运行,但它们对应的本地时间是每年两次以一小时为单位的轮班。

@daily 的相同 0 0 * * *嗎?

是的- @daily (及其同义词) @midnight) 扩展到精确 0 0 * * * vixie cron中。两个注意事项。首先,toolz。dev解析器只接受五个字段的表达式,所以粘贴 0 0 * * * 而不是 @daily 为现在。第二,每 @daily job同时瞬间开火,所以一个服务器有很多他们得到午夜负载飙升,每天的工作分散在交错的分钟和小时,避免了那个自作自受的雷霆群。

Toolz。dev cron 解析器是否上传我的表达式?

号的 克朗解析器 完全在浏览器中运行 - 表达式是解析的客户端,永远不会发送到服务器、记录或存储。由于 crontabs 揭示了备份定时和计费运行等操作细节,因此将其与第三方服务器隔离是明智的默认值,您可以自行确认浏览器中的行为's 网络选项卡。

在发货之前请先阅读它

5周的摘要邮件晚一天到达并不是戏剧性的中断,没有人给我打电话。那's正是导致调度错误昂贵的原因:他们不't宣布自己,他们只是悄悄地做错了事情,直到一个客户顺便提到它为我修复的习惯是't纪律或更好的记忆力现场订购 - it's一个三十秒的读回。粘贴表达式,阅读英文句子,查看五个具体日期,然后部署。

保持 克朗解析器 在您'在同一个调试会话中触及的工具旁边: 时间戳转换器 当下一次运行时间需要在区域之间移动时(I've 写入了 Unix 时间戳陷阱 那咬得最厉害), 日期差计算器 用于理智检查间隔,以及 文本差异工具 当你'在迁徙过程中将旧的crontab与新的crontab进行比较时。 编码工具指南 浏览该集如何组合在一起,所有内容都会运行客户端 - 对于准确记录备份和计费运行时起火的文件,这是唯一合理的默认值。

Frequently Asked Questions

A cron expression parser is a tool that reads crontab syntax — like */15 9-17 * * 1-5 — and translates it into a plain-English schedule description, typically alongside a preview of the next execution times. It lets you verify what a schedule actually does before deploying it, instead of discovering a misread field when a job fires at the wrong time in production.

Comments

0 comments

0/2000 characters

No comments yet. Be the first to share your thoughts!