日時・スケジュール
平日の9時から17時まで15分おきのCronを確認したい
使うツール
バックアップを平日の朝だけ動かしたい。Cronの式を検索して貼り付ければ準備はできそうですが、五つの数字が読めることと、意図した日時に動くことは別です。曜日を追加したつもりで実行日を増やしたり、開始時刻と同じ候補が出ないことを不具合だと思ったりすることがあります。式の説明を読むだけでなく、実際の日付を並べて確認しましょう。
まず、平日の9時を三回並べる
0 9 * * 1-5Cron生成・確認へこの式を入れ、タイムゾーンをAsia/Tokyo、開始時刻を2024-01-05T00:00:00Z、候補数を3にします。開始時刻は東京では金曜9時です。結果は1月8日、9日、10日の00:00:00Zとなり、東京の月曜から水曜の9時に対応します。Z付きの出力はUTCなので、数字だけを見て深夜のジョブになったと思わないようにします。
この例で除外しているのは土日であり、祝日ではありません。1月8日がその地域の休業日でも、Cron式だけでは避けられません。『平日』が月曜から金曜を意味するのか、会社の営業日を意味するのかを先に決めます。休日除外が必要なら、営業日計算で日付を確認したうえで、実行側にも別の条件が必要です。
開始時刻ちょうどの候補は含まれない
候補は指定した開始時刻より後を探します。先ほどの金曜9時は式に一致していても結果に入りません。開始を2024-01-04T23:59:59Zへ一秒戻すと、最初の候補は1月5日00:00:00Zになります。『この瞬間も含めた一覧』が欲しい場合と『この瞬間の次』が欲しい場合を区別すると、一回不足して見える理由を説明できます。
再現したい不具合を相談するときも、式だけでなく、タイムゾーンと固定した開始時刻を添えます。『今から10件』では、確認する人や日によって結果が変わります。月末や曜日の問題なら、その境界の少し前を開始にすると、疑わしい部分を短い一覧で調べられます。
『1日で、かつ月曜』のつもりが違う
0 9 1 * 1このツールの候補計算では、日と曜日の両方が指定されるこの式は、毎月1日または月曜の9時に一致します。UTCで2024-05-31T00:00:00Zから並べると、6月1日（土曜）、3日（月曜）、10日（月曜）が出ます。『1日が月曜のときだけ』という意味にはなりません。条件を足すほど必ず絞り込まれる、という一般的な検索の感覚が通用しない箇所です。
曜日の数値は0と7が日曜、1が月曜です。月名や曜日名、L・#・?などを含む式、秒を含む6フィールド式、Quartzやクラウド独自の書式はここでは受け付けません。元サービスから式を移すときに、余った先頭フィールドを機械的に削るのも危険です。どの欄が秒・年などを表すのかを元の仕様で確かめてから、対応範囲の式として作り直します。
*/20は『前回から20分』ではない
*/20 * * * *09:07に開始しても、次は09:27ではなく09:20です。Cronは指定した欄の値に一致する時刻を選び、前回の処理完了から一定時間を待つタイマーではありません。処理に25分かかっても、この式が次の候補を自動的に遅らせるわけではありません。実行が重なったときの排他、失敗後の再試行、停止中に過ぎた予定の扱いは、別に実行基盤で決めます。
夏時間の2時は、候補を現地時刻に戻して読む
America/New_Yorkで毎日2時の式0 2 * * *を、2024-03-09T08:00:00Zから確認します。本ツールの最初の候補は2024-03-10T07:00:00Zで、その地域では3時です。切替日に2時が存在しないため、採用しているパーサーがこのように候補を扱います。翌日は06:00:00Z、現地2時へ戻ります。『存在しない時刻は必ずスキップされる』と一般化してはいけません。
秋に時計が戻って同じ時刻が二度現れる場合も、二回動くか一回に抑えるかは実行基盤の仕様を確認します。このツールの一覧は採用ライブラリの候補であり、サーバーのCron、クラウドのスケジューラー、ジョブ管理製品の実行保証ではありません。UTCで固定すれば現地の時刻が変わり、現地の時刻で固定すれば経過時間が変わることも、運用要件として選びます。
式を登録する前に残す確認メモ
まず通常の週、月末、夏時間の切替付近を別々の開始日時で確認します。候補は最大100件、探索範囲は開始から5暦年までです。必要な候補が見つからず上限になる場合は、成功した空一覧と解釈せず、式と対象期間を見直します。年に一回の予定を100件要求するような使い方は、この確認範囲に収まりません。
引き継ぎには、式、地域、開始日時、期待する最初の数件、休日と重複実行の扱いを一緒に残すと役立ちます。SheepDevはジョブを登録せず、コマンドを実行しません。ここで疑問を小さな具体例へ変え、実際に動かす環境の仕様と照合するところまでが確認作業です。
次の十件だけでは、月末の抜けを見つけられない
毎月31日の実行を考えて『0 9 31 * *』とした場合、31日がない月に自動的に月末へ補正する式ではありません。1月の次に2月末を期待していても、単純な31日指定ではその条件になりません。次回候補を並べ、2月や4月のように31日がない月をまたいで確認します。『毎月同じ日』『月末』『前回から30日後』は、似ていても違う予定です。この画面が受け付ける五フィールドの記号だけで表せない条件を、見た目が近い式へ置き換えて完成にしないようにします。
同様に、毎分の式が十件正しく並んでも、重い処理が一分以上かかったときの重複実行はこの計算から分かりません。前の処理が終わるまで待つ、次の回を飛ばす、別の処理として並行実行する、といった判断は実行基盤側の仕様です。候補時刻を確認する作業と、ジョブの排他制御や再実行を設計する作業を分けます。Cron式が正しいことは、処理が実際に完了したことや失敗後に安全にやり直せることの証明ではありません。
確認用には、通常の週、月をまたぐ日、年をまたぐ日、対象地域の夏時間切替付近というように、開始日時を変えた複数の候補一覧を残します。毎回同じ『現在から』だけで確かめると、実行日によって確認した条件が変わります。開始日時とTimezoneを固定しておけば、式を直した後も同じ期待値と比較できます。検索上限で候補が見つからなかった場合は、無限の未来に一度も実行しないと断言せず、調べた範囲内の結果として扱います。