タイムゾーンとプラットフォーム

同じ cron 文字列でも、解釈者とタイムゾーン次第で異なる瞬間に発火します。

Linux ユーザー crontab

サーバー上の従来の crontab は通常、マシンのローカルタイムゾーン（/etc/timezone や timedatectl で設定）で式を評価します。

サーバーが地域移転したり DST ルールが変わると、OS レベルで UTC に標準化しない限り、壁時計スケジュールはずれます。

Kubernetes CronJob

CronJob 仕様は標準 5 フィールド cron を使います。Kubernetes 1.25 以降、timeZone フィールドで IANA ゾーン（例：Asia/Tokyo）を指定でき、コントロールプレーンのローカル時刻を継承する必要がありません。

明示的ゾーンがなければ、kube-controller-manager 設定に依存します。ラップトップのローカル時刻を前提にしないでください。

GitHub Actions

on.schedule の cron は常に UTC で解釈されます。ワークフローごとのタイムゾーンフラグはありません。

Actions の 0 9 * * 1-5 は平日 UTC 09:00 を意味します。上海やサンフランシスコの 09:00 ではありません。ローカルオンコール時間と調整するときは意識的に変換してください。

Quartz、AWS EventBridge、拡張

一部システムは 6 フィールド（秒が先）や「特定値なし」の ? プレースホルダーを使います。Linux 行を Quartz に翻訳せずコピーするのは頻繁なバグです。

ベンダー間で式を再利用する前にプラットフォーム文法表を読んでください。

DST エッジケース

「毎日 02:30」のようなスケジュールは、ローカルゾーンで DST 開始/終了時に 1 時間スキップまたは重複することがあります。UTC ベースのスケジュールはそのクラスのバグを避けますが、ローカル営業時間との相対でずれます。

正しいゾーンでプレビュー

検証するときは常に問いかけ：

1. どのエンジンがこのジョブを実行するか？
2. そのエンジンはどのタイムゾーンを使うか？
3. そのゾーンと UTC で次の 3 回の発火時刻は何か？

要点

ランブックの各 cron 行の横にタイムゾーン + プラットフォームを文書化してください。「毎日 9 時」は誰の時計か分からなければ意味がありません。

Cron Expression Parser で次回実行をプレビューしてください。