秋の時間変更の時間中にスケジュールされたジョブ

他の人がこのシナリオをどのように扱っているのだろうかと思っています。

午前1:30に実行するようにスケジュールされたジョブがある場合はどうなりますか。秋になると、時間が変わると、1：00：00から1:59:59までの時間が繰り返され、ジョブが2回実行されます。

Windowsタスクスケジューラ、SQLエージェント、またはその他のスケジューリングツールを使用できます。これらのツールのほとんどは、UTC時間ではなくマシン時間に基づいているようです。毎晩UTC時間にジョブを実行するように指示した場合、重複した時間の問題は発生しません。

タイムゾーンと夏時間を考慮した、現地時間による将来のタスクの適切なスケジューリングは、非常に複雑なテーマです。Stack Overflowのプログラミングの観点から、これについてはこことここで書きました。

非プログラミングの観点から要約します。

• UTCではなく現地時間で繰り返しパターンを定義します。たとえば、毎日午前8時に起床するように毎日の目覚まし時計を設定している場合、夏時間の移行後1時間早く、または1時間遅く目を覚ますのは望ましくありません。米国太平洋時間帯にいる場合、UTC 4:00 PMにスケジュールすることはできません。移行後、現地時間の8:00 AMを維持するためにUTC 3:00 PMに切り替える必要があるためです。

• 「ローカル」時間が表すタイムゾーンを定義します。サーバーのローカルタイムゾーンがエンドユーザーにとって重要なタイムゾーンと同じであると想定しないでください。

• プロジェクトあなたは火災にイベントをしたいという各出現についてUTCの日付と時刻をローカルタイムを。

  • UTCクロックを使用して実行する実際の瞬間を決定できるように、次の即時発生に対してほとんど常にこれを行います。

  • では、いくつかのケースでは、あなたはまた、このような次の5つの出現、または来年のすべての出現として、次のいくつか（または多くの）インスタンスを、投影することができます。（この部分は、アプリケーションの要件に非常に固有です。）

• 夏時間への移行時に発生するオカレンスに対して何を行うかの戦略（固定または構成可能）を用意します。

  • 「スプリングフォワード」トランジションの場合、オカレンスが存在しない可能性があるときに、ローカルタイムが欠落しているギャップがあります。たとえば、米国太平洋時間では、現地時間の午前2時に実行するようにスケジュールされた毎日のタスクは2014年3月9日に存在しません。ほとんどの場合、節約時間（通常1時間）だけその時間を進めます。 ）、その日は午前3時に実行されますが、次のインスタンスでは午前2時に実行に戻ります。（ただし、これには別の戦略が必要になる可能性があります。）

  • 「フォールバック」遷移の場合、オカレンスが2回存在する可能性があるときに、複製されたローカル時間の重複があります。たとえば、米国太平洋時間では、午前1時に実行するようにスケジュールされた毎日のタスクは、2014年11月2日に実行できる可能性がある2つの時間を持ちます。ほとんどの場合、最初の1 ：00 AM PDTで、同じ日付の次のオカレンスである1:00 AM PSTをスキップします。（ただし、2度目に実行する、または両方で実行するなど、別の戦略が必要な場合があります。YMMV）

• タイムゾーンデータを更新する必要がある場合は、発生するすべてのUTC時間を再計算する準備をしてください。IANA /オルソンTZDBの複数の更新アウトプット毎年ので、自分のタイムゾーンオフセットおよび夏時間のルールについての世界の変化を彼らの心のすべての時間の政府。 ルールが変わらないと将来の特定の期間について仮定できません。

  • タイムゾーンデータリリースのアナウンスを購読し、それらをシステムやアプリケーションに適用するプロセスを用意してください。

  • 従来の企業環境では、これはIT運用スタッフの責任である必要があります。

  • ご使用の環境によっては、tzdataLinuxパッケージの更新、Java JREまたはtzupdater、または他の任意のチャネルを介してこのデータを取得する場合があります。PHPのtimezonedb PECLパッケージなど、環境固有のものやプログラミングプラットフォーム固有のものがあります。

  • Microsoftには独自のタイムゾーンデータがあります。Windowsでは、TimeZoneInfoたとえば.NETから使用している場合、このデータを使用しています。更新はここから取得され、Windows Updateを介して自動的にプッシュされるため、再計算する必要があるかどうかを確認できるように注意してください。

• これらすべてを理解した上で、UTCだけでスケジュールするシナリオがまだあります。それは将来の絶対的なイベントのためです。例：

  • X時間ごとまたはX分ごとに実行されるジョブ。

  • 日の出の開始時刻と終了時刻、またはその他の天文現象。

  • 事前に決められた時間に機密情報を別の関係者に送信する場合など、時間に依存するセキュリティウィンドウ。

Windowsタスクスケジューラ

Windowsは必ずしも正しいことをしているわけではありません。トリガーの定義方法に注意してください。

[タイムゾーンを越えて同期する]チェックボックスをオンにすると、タスクはUTCのみでスケジュールされます。（すべての時間は現地時間として表示されますが、保存されますれ、UTCとしてれます。）これは、以前「絶対」イベントと呼んでいたものです。

このボックスをオフのままにすると、コードが実行されているコンピューターのローカルタイムゾーンが使用されます。タイムゾーンを指定するオプションは提供されないため、これはあまり良い実装ではありません。

DSTの振る舞いについては正確にはわかりませんが、実験して、それについてお話しします。おそらく上記で説明したことを実行しますが、必ずしもそうではありません。

SQLエージェント

SQL Agentスケジューラは、ローカルサーバーの時間しか使用できないという点でさらに悪いです。繰り返しますが、タイムゾーンは指定できません。また、UTCも指定できません。

要求されましたが、受け入れられません。

気にしないことで、一般的に。

「タスクが2回実行されたらどうなるでしょうか？」という質問をします。

一般的に、それは重要ではないので、何もする必要はありません。それが問題になる場合、最も簡単な解決策は、夏時間の変更の影響を受ける時間外にジョブを移動することです。

前述のとおり、午前1時から午前2時までの時間がDSTの終わりに繰り返されます。逆の変更（DSTの開始）が発生すると、午前2時から午前3時までの時間は発生しません（ジョブは実行されません）。あなたの最良の選択肢は

• UTCにジョブスケジュールを実行します
• 切り替え外（12:59 AMまたは3AM）に一度にジョブを実行する