日本語

開発者ツール · Crontab ジェネレーター

cron にタイムゾーンフィールドがない理由: 現地時間、CRON_TZ、およびコンテナーは UTC

· 背景

クロン タイムゾーン スケジュール設定

UTC、東京、およびニューヨークの時計を指す 1 つの 5 フィールド式
オリジナル ToolAcre ベクトル イラスト

cron 式にはタイムゾーンが含まれていないため、同じ 5 つのフィールドはホストごとに異なる時刻を意味します。この投稿では、cron が使用するクロック、CRON_TZ 拡張機能、およびコンテナーによって答えが変わる理由について説明します。

選択したゾーンが変更されると、同じフィールドで異なるプレビュー インスタントが生成されます

`0 9 * * *` には時間は含まれますが、場所は含まれません。 ToolAcre では、UTC または Asia/Tokyo を選択すると、5 つのフィールドは変更されず、09:00 の壁時計の各候補によって表される瞬間が変更されます。したがって、2 つの環境が異なるゾーンで同じローカル ラベルを解釈する場合、レポートは数時間離れて表示されることがあります。

パネルは、「次の実行を表示」セレクターを使用して、この依存関係を明示します。スケジュールを確認するときに対象のマシンのゾーンを使用し、その仮定を式の横に記録します。選択はブラウザのプレビューにのみ影響します。コピーされた cron テキストには埋め込まれません。

式にはゾーンが含まれていません。外部デーモンのクロック選択はここでは構成されていません

フィールド仕様は正確に 5 つありますが、名前付きタイムゾーンはありません。 `nextRuns` はゾーンを別個のオプションとして受け入れ、JavaScript で認識されるホスト環境をデフォルトとします。この分離は、ゾーン コンテキストが ToolAcre のモデルの式の外部にあることを証明します。

ワークブックは、各デーモンがどのクロックを読み取るかを要求しました。このリポジトリはデーモンを構成したり検査したりできないため、その普遍的な動作は確立されません。プレビュー ゾーンをターゲットの文書化された解釈と照合し、インストールされているスケジューラーを個別に検証することのみをアドバイスできます。

CRON_TZ サポートはこのパーサーの範囲外にあり、要求されていません

`CRON_TZ` は解析されません。式ボックスにこれを入力すると、フィールドが 5 つではなく、フィールドごとのコントロールにディレクティブが保存されないため、失敗します。ワークブックでは、ある実装ではサポートされているが、他の実装ではここに記載されていないソースは必要ないと主張しています。

ターゲットにタイムゾーン ディレクティブが文書化されている場合は、そこで設定してテストします。 ToolAcre が式をコピーするときにディレクティブを保持することを期待しないでください。ターゲット固有の構成がレビューされてデプロイされるまで、ゾーンのメタデータをスケジュールに隣接させたままにしておきます。

TZ 環境セマンティクスはモデル化されていません

`TZ` 割り当ても同様にスコープ外です。ブラウザーは、crontab ファイル内の環境行ではなく、明示的な `timeZone` オプションをフォーマットと変換に使用します。別のシステムでは、割り当てによってスケジュール評価が変更されるのか、コマンド出力が変更されるのか、あるいはその両方が変更されるのかがわかりません。

この修正により、微妙だがコストのかかる仮定が回避されます。類似した名前は、同じ役割を意味するものではありません。スケジューラ ゾーンの選択とプロセス環境を別個の質問として扱い、式ジェネレータからではなくターゲット実装から両方に答えてください。

コンテナとクラウドのデフォルトにはターゲットの証拠が必要です

コンテナーとクラウド イメージはルートによって検査されません。 Docker ソケット、ホスト クロック、メタデータ サービスはクエリされません。デフォルトが UTC であるという主張は、特定の展開では真実である可能性がありますが、読者のブラウザで実行されている `Intl.DateTimeFormat` から一般化することはできません。

文書化されたツールと構成を通じて実際のターゲット ゾーンをキャプチャします。次に、利用可能な場合は ToolAcre で同じ IANA 名を選択します。ブラウザーのゾーン リストには、そのエンジンが認識している内容が反映されます。ターゲットに同一のゾーン データまたは設定が含まれていることを証明するものではありません。

動作例: 季節変換をハードコーディングせずに、選択した 2 つのゾーンで 09:00 をプレビューする

`0 9 * * *` を固定したままにして、UTC で 1 つの結果をプレビューし、次にアメリカでプレビューします/New_York. 各リストには、実時間として 09:00 が表示されますが、エポック インスタントは該当するゾーン オフセットによって異なります。地域オフセットは日付によって異なる可能性があるため、1 つの永続的な時間換算を公開することは避けてください。

テストでは、UTC と東京の深夜、および将来の変更を伴うロンドンの毎日のジョブでこの原則を実証します。検討中の日付の現在の候補を使用します。デプロイメントによってスケジュールが固定 UTC 時間に変換される場合は、1 つの値がローカルの 09:00 を永久に保持することを暗示するのではなく、季節制限を文書化します。

DST 候補の処理は ToolAcre のプレビュー動作であり、デーモンの保証ではありません

ToolAcre は候補をローカル カレンダー コンポーネントとして構築し、ブラウザー ゾーン データを通じて変換します。存在しないスプリングフォワード時間は省略され、通常の毎日の時間は、テストされた移行全体にわたって同じ現地時間のままです。これらはプレビュー実装の事実です。

デーモンやクラウド スケジューラの実行を保証するものではありません。ジョブが実行される移行ポリシーを確認します。プレビューによってリスクが明らかになり、予想される瞬間が提供される一方、展開されたスケジューラーはアクションが開始されるかどうかの信頼できる観察を提供します。

要点: スケジュールはそのゾーンでのみ完成します — ジェネレーターでフィールドを構築し、その横にタイムゾーンを記録します

スケジュールは、その 5 つのフィールドが構文的に完全であっても、ゾーン コンテキストがなければ操作上不完全です。 ToolAcre は、ゾーンを別のセレクターに保持し、結果として得られる壁時計リストを表示することで、その真実を表します。コピーされた式だけでは選択を行うことができません。

式とゾーンを一緒に記録し、ターゲット構成を確認し、オフセット変更付近の候補を再検討します。ジェネレーターはスケジュールを作成して説明します。サーバークロックを設定したり、タイムゾーンディレクティブを書き込んだり、実行を約束したりすることはありません。この境界により、制御を誇張することなくプレビューが有用に保たれます。