写表达式前先描述目标瞬间
先写出类似“每个工作日欧洲/柏林时间 09:00 运行”或“在 2026-10-01T00:00:00Z 过期”的句子。没有时区的时钟时间不完整，没有单位的大整数也不完整。请同时记录人类需求和机器表示，便于复核。
当一个事件必须在全球同一瞬间发生时使用 UTC；当计划要遵循当地办公时间时使用命名的本地时区。二者在夏令时变化附近含义不同：本地 09:00 会遵循该地日历，而 UTC 计划保持同一世界时刻，在当地可能显示为不同钟点。
使用正确的 Cron 段数和方言
本 Cron Expression Parser 支持 5 段：分、时、日、月、星期；也支持 6 段，其中第一段为秒。例如 `*/5 * * * *` 是 5 段形式的每五分钟，`*/30 * * * * *` 是 6 段形式的每三十秒。选择 6 段不只是增加精度，而会改变每一段的解释位置。
Cron 并不是唯一通用语言。服务器、云平台、框架或 CI 系统对字段、名称、特殊字符、星期规则和时区设置可能不同。浏览器预览适合理解候选表达式，但最终必须在实际运行任务的调度器中测试。
在计划所属时区预览未来执行
选择计划所属时区，再检查未来 5、10 或 20 次执行。解析器会同时显示所选时区和 UTC。应检查最容易暴露问题的边界：午夜、月末、周末、目标工作日范围，以及该时区有夏令时时制变化前后的日期。
预览从当前浏览器时钟开始，是预测而不是服务器行为记录。请与运行环境实际时区和部署特有的调度设置对照。重要操作应加入记录实际执行时间并对漏跑或重复运行告警的监控。
写出业务规则。
用自然语言说明本地或 UTC 时间、时区、重复规则和日期边界。
选择 Cron 方言。
确认实际调度器需要 5 段、6 段还是其他语法。
预览多次执行。
使用所属时区，并检查正常日期和相关边界。
在目标系统测试。
在 staging 或获批准的生产安全测试中验证同一表达式和时区。
区分 Unix 秒和毫秒
Unix 时间通常以自纪元以来的秒表示，但 JavaScript Date 和许多 API 使用毫秒。`1719388800` 是秒，`1719388800000` 是毫秒。Timestamp Converter 的自动选项会把绝对值达到 100000000000 的数字作为毫秒，更小的数字作为秒。该规则对普通现代时间戳很方便，但只要来源契约明确，就应显式选择单位。
转换器接受数字时间戳，并显示 Unix 秒、Unix 毫秒、本地时间、UTC 和 ISO 8601。转移数值前至少核对两种表示。相差 1000 倍的时间戳也可能转换为看似有效的日期，只是会偏离目标数百年。
明确本地时间与 UTC 的解释方式
`datetime-local` 值没有时区偏移。把日期时间转为时间戳时，请选择可见字段代表浏览器设备的本地时间还是 UTC。例如，一个地点输入的本地 09:00 与 09:00 UTC 可能是不同瞬间。使用输出的 ISO 8601 值和 UTC 显示验证要分享的确切瞬间。
两个工具都在浏览器本地运行，Cron 表达式或时间戳输入不会上传到 MV Tools。但真正的运行计划和事件时间仍应在所属系统中保持准确，并在文档、日志、告警和 API 中采用一致时区约定。
常见问题
为什么 Cron 在错误的小时运行？
调度器可能使用了不同的时区或 Cron 方言。请检查其配置时区、段数，并在同一环境中预览未来执行。
如何区分 Unix 秒和毫秒？
现代 epoch 秒通常约十位，毫秒约十三位。自动模式以 100000000000 为阈值，但来源契约已说明单位时应明确选择。
Cron 表达式有效是否表示任务一定运行？
不表示。它只说明可被解析为计划；运行环境还需要调度器启用、正确时区、权限、部署配置和监控。