开发者工具 · Crontab 生成器

为什么 cron 没有秒字段，六字段表达式从何而来

2026年3月9日 · 背景

计划任务方言验证

六字段表达式不是 cron 表达式，尽管它看起来像一个。这篇文章解释了为什么 Unix cron 在几分钟内停止，以及 Quartz、Spring 和云调度程序如何扩展语法。

六字段表达式属于另一种调度程序样式，而不是此解析器

当 ToolAcre 看到六个空格分隔的部分时，它会拒绝它们并解释其格式恰好有五个位置：分钟、小时、月份、月份和星期。该消息指出，Quartz 或类似 systemd 的语法中出现了前导秒样式。它不会默默地丢弃第一个令牌。

这种拒绝可以防止职位腐败。在不了解源语法的情况下删除标记可能会改变每个剩余的值。翻译首先确定每个源字段的含义以及预期的时间表是否可以在五个字段目标中表示。

实现的字段数组从分钟开始，到工作日结束。不存在秒或年规范。测试需要精确的字段计数并拒绝较短和较长的表达式。这足以记录当前的语法。

该工作簿提供了基于每分钟唤醒一次守护进程的历史解释。该存储库不包含证明该来源所需的存档实现。因此，文章只说 ToolAcre 的模型具有分钟分辨率，并且没有秒位置。

源错误消息将 Quartz 命名为秒优先样式的示例，但解析器不实现 Quartz 运算符或可选位置。诸如 `?`、`L`、`W` 和 `#` 之类的字符无法被普通值读取器读取。它们不会被翻译或解释为支持的语法。

避免使用 ToolAcre 作为 Quartz 验证器。有效的源表达式可以编码五字段 cron 无法表示的关系。阅读源文档，用文字陈述需求并仅重建目标语法支持的部分。

工作簿中的框架和云调度程序名称需要各自的当前文档。该存储库没有 Spring、EventBridge、Kubernetes 或 GitHub Actions 计划架构。它们的字段计数、别名和时区策略不应该在这里凭记忆进行总结。

相似不是兼容性。两个产品都可以调用字符串 cron，同时分配不同的位置或日期语义。 ToolAcre 严格的五字段解析器很有价值，因为它在边界处停止，而不是接受无法保留含义的表达式。

假设源要求是在工作日的 9 到 17 时间内每十五分钟一次，并且没有任何外部运算符具有附加含义。在 ToolAcre 中，可表示的形式是 `*/15 9-17 * * MON-FRI`。解析器扩展刻钟、包含时间和命名工作日。

描述和预览随后公开目标解释，包括 17:45 处的最终每日候选。在调用等效翻译之前，将其与源调度程序的实际行为进行比较。五字段形式仅适用于翻译过程中建立的口头要求。

无法表达亚分钟的工作，因为分钟是最小的字段。该工作簿建议在命令内使用循环，但 ToolAcre 不会生成、执行或监督循环。这种模式在其日历模型之外引入了计时、重叠和关闭问题。

选择为所需分辨率设计的运行时并在那里进行验证。不要通过将秒数放在分钟槽中来将秒数要求伪装成五字段 cron。尽管在某些情况下通过了数字验证，但生成的时间表会更慢并且语义上有所不同。

其他语法中的月末和序数工作日运算符也在范围之外。删除它们可能会不可预测地扩大或缩小日期。 ToolAcre 支持普通值、名称、范围、列表和步骤，以及其记录的别名；该集合定义了翻译上限。

当需求超过上限时，报告“不可表示”并保留支持它的调度程序或重新设计操作。解析时发生的有损重写比明显的不兼容性更糟糕，因为它创建了看似合理但不正确的未来日期。

首先计算字段数，其次识别源方言，最后翻译要求（而不是标点符号）。 ToolAcre的错误使得第一步不可避免，其描述提供了重建后的目标端检查。

该路由仅生成五字段表达式。它不验证秒、年或特定于调度程序的运算符，并且不调度作业。这些遗漏定义了一个可靠的边界，该边界在每次迁移讨论中都应保持可见。