开发者工具 · Crontab 生成器
为什么 cron 没有时区字段：本地时间、CRON_TZ 和 UTC 的容器
· 背景
计划任务 时区 调度
cron 表达式中没有时区，因此相同的五个字段在不同主机上表示不同的时刻。这篇文章解释了 cron 使用哪个时钟、CRON_TZ 扩展以及容器更改答案的原因。
当所选区域更改时，相同的字段会产生不同的预览时刻
`0 9 * * *` 包含一个小时，但没有位置。在 ToolAcre 中，选择 UTC 或 Asia/Tokyo 会使五个字段保持不变，同时更改每个 09:00 候选挂钟所代表的时刻。因此，当两个环境解释不同区域中的相同本地标签时，报告可能会相隔数小时出现。
面板通过“显示下一个运行”选择器使这种依赖关系变得明确。查看计划时使用目标机器的区域，然后在表达式旁边记录该假设。该选择仅影响浏览器预览；它没有嵌入到复制的 cron 文本中。
表达式不包含区域；此处未配置外部守护程序时钟选择
正好有五个字段规范，没有命名时区。 `nextRuns` 接受区域作为单独的选项，并默认为 JavaScript 看到的主机环境。这种分离证明了区域上下文对于 ToolAcre 模型中的表达式来说是外部的。
工作簿声明每个守护进程读取哪个时钟。该存储库无法配置或检查守护程序，因此它无法建立通用行为。它只能建议将预览区域与目标记录的解释相匹配，并独立验证已安装的调度程序。
CRON_TZ 支持在此解析器之外，未声明
`CRON_TZ` 未解析。在表达式框中输入它会失败，因为它不是五个字段，并且没有每个字段控件存储指令。该工作簿声称一种实现支持它，而其他实现则不需要此处未提供的源。
如果目标记录了时区指令，请在那里配置并测试它。不要期望 ToolAcre 在复制表达式时保留指令。使区域元数据与计划相邻，直到审查和部署特定于目标的配置。
TZ 环境语义未建模
`TZ` 赋值同样超出范围。浏览器使用显式 `timeZone` 选项进行格式化和转换，而不是 crontab 文件内的环境行。它无法判断任务是否改变了另一个系统上的计划评估、命令输出或两者都没有。
此修正避免了微妙但代价高昂的假设。相似的名称并不意味着相同的角色。将调度程序区域选择和进程环境视为单独的问题，并从目标实现而不是从表达式生成器回答这两个问题。
容器和云默认需要目标证据
容器和云镜像不被路由检查。不查询 Docker 套接字、主机时钟或元数据服务。声称它们默认为 UTC 在特定部署中可能是正确的，但不能从读者浏览器中运行的 `Intl.DateTimeFormat` 进行推广。
通过其记录的工具和配置捕获实际的目标区域。然后在 ToolAcre 中选择相同的 IANA 名称（如果可用）。浏览器区域列表反映了其引擎所知道的内容；它不能证明目标包含相同的区域数据或设置。
工作示例：在两个选定区域中预览 09:00，无需硬编码季节性转换
保持 `0 9 * * *` 固定，并在 UTC 中预览一个结果，然后在美国/New_York. 每个列表均显示 09:00 作为挂机时间，但纪元时刻因适用的区域偏移量而异。避免发布一小时的永久换算，因为区域偏移量可能会随日期而变化。
这些测试通过 UTC 和东京午夜以及伦敦日常工作在向前变化中证明了这一原则。使用正在审核的日期的实时候选人。如果部署将计划转换为固定的 UTC 小时，请记录季节性限制，而不是暗示某个值永远保留本地 09:00。
DST 候选处理是 ToolAcre 预览行为，而不是守护程序保证
ToolAcre 将候选项构建为本地日历组件，并通过浏览器区域数据将其转换。省略了不存在的春进时间，并且在经过测试的过渡期间，普通的每日时间仍然与本地时间相同。这些是预览实施事实。
它们不是守护程序或云调度程序的执行保证。验证作业将在其中运行的转换策略。预览可以揭示风险并提供预期的时刻，而部署的调度程序则提供对操作是否开始的权威观察。
要点：时间表仅包含其区域 - 在生成器中构建字段，然后在它们旁边记录时区
如果没有区域上下文，时间表在操作上是不完整的，即使它的五个字段在语法上是完整的。 ToolAcre 通过将区域保留在单独的选择器中并显示生成的挂钟列表来代表这一事实。单独复制的表达式不能包含选择。
一起记录表达式和区域，验证目标配置并在偏移更改附近重新访问候选者。生成器创建并解释时间表；它不设置服务器时钟、编写时区指令或承诺执行。该边界使预览保持有用，而不会夸大控制。