Cron 式
書いた式が正しいか不安ですか？次にいつ実行されるかを見るのが一番わかりやすいです。
分(0-59) 時(0-23) 日(1-31) 月(1-12) 曜日(0-7、0 と 7 はどちらも日曜)。未対応： @daily こうしたマクロや秒単位のフィールド（それは Quartz の 6 段形式です）。
使う場面
- 引き継いだ crontab や CI のスケジュールで、*/15 9-18 * * 1-5 が実際に何時から何時まで動くのか、昼休みをまたぐのか、週末は本当に動かないのかを確認したいとき。
- 式を書き換えた後、次の 8 回が想定どおりの時刻に来るか、特に 31 日、2 月、月末のような目で追いにくい境界を確かめたいとき。
使わないほうがよい場面
- Quartz や Spring の @Scheduled のように秒を先頭に置く 6 段、あるいは AWS EventBridge の 6 段を書く場合。フィールドの並びもタイムゾーンの規則も異なり、本ツールはちょうど 5 段しか受け付けません。
- @daily や @reboot のマクロ、L、W、# の拡張、IANA タイムゾーンの指定が必要な場合。いずれも非対応です。crontab(5) を参照するか、システムやスケジューラ側のタイムゾーンを変更してください。
解析と次回時刻の算出はブラウザ内で完結し、端末のタイムゾーンを使います。サーバ側の設定は参照しません。制限：ちょうど 5 段で、数字、*、範囲、リスト、/ステップのみ。JAN/MON のような名前、@daily マクロ、L/W/#/?、秒フィールドは非対応です。日と曜日を両方指定した場合は AND で計算します（Vixie cron は OR）。2 年先までの中で最大 8 回を表示します。
よくある質問
タイムゾーンはどれですか？
ブラウザのローカルタイムゾーンです。サーバのタイムゾーンに換算することは、このページにはできません。多くの crontab は UTC かシステムのローカル時刻で動きます。VPS は UTC が普通で、コンテナはほぼ UTC です。同じ 0 9 * * * でも、北京と UTC のホストでは 8 時間ずれます。公開前に date と timedatectl で対象マシンの設定を確認してください。夏時間の切り替えでは、存在しなくなるローカル時刻は実行されず、重複するローカル時刻は 2 回実行されることがあります。
@daily や @reboot は使えますか？ Quartz の ? や秒は？
どれも使えません。@daily は 0 0 * * *、@weekly は 0 0 * * 0 と書いてください。@reboot は起動イベント依存で、式では表現できません。Quartz の ?（未指定）、L（月末）、W（直近の平日）、#（第何週の何曜日）と秒フィールドは別の文法です。本ツールは 5 段のみを解析し、数字、*、範囲、リスト、/ステップに対応します。JAN や MON のような名前は解釈しません。
日と曜日を両方指定するとどうなりますか？
本ツールでは AND です。両方を満たすときだけ実行するため、0 0 1 * 1 は「1 日かつ月曜日」となり、数年に一度しか該当しません。標準の Vixie cron は OR で、どちらかを満たせば実行します。ここは間違えやすい差異で、「ジョブが動かない」調査でよく引っかかります。片方だけを指定してもう片方は * にしておくのが安全です。複雑な条件はスケジューラかコード側で判断してください。