秋の時間変更の時間帯にスケジュールされたジョブ
他の人がこのシナリオをどのように扱っているのだろうと思います。
午前1:30に実行するようにスケジュールされたジョブがある場合はどうでしょうか。秋になると、時間が変わると1:00:00から1:59:59の時間が繰り返され、ジョブが2回実行されます。
Windowsタスクスケジューラ、SQLエージェント、またはその他のスケジュールツールを使用できます。これらのツールのほとんどは、UTC時間ではなく、マシン時間に基づいているようです。毎晩UTC時間にジョブを実行するように指示した場合、重複した時間の問題は発生しません。
タイムゾーンと夏時間を考慮して、現地時間で将来のタスクを適切にスケジュールすることは、非常に複雑なテーマです。 Stack Overflow here と here のプログラミングの観点から、以前にそれについて書きました。
非プログラミングの観点から要約します。
local時間-ではなくUTCで繰り返しパターンを定義します。たとえば、毎日午前8時に起きるように毎日の目覚まし時計を設定した場合、夏時間の移行後に1時間早くまたは1時間遅れて目覚めたくはありません。米国太平洋時間帯にいる場合、4：00 PM UTCのスケジュールを設定することはできません。移行後に3:00 PM現地時間の午前8:00を維持するためのUTC。
「現地時間」が表すタイムゾーンを定義します。サーバーのローカルタイムゾーンが、エンドユーザーにとって重要なタイムゾーンと同じであるとは限りません。
Projectイベントを発生させる各発生のUTC日時までの現地時間。
ほとんどの場合、次の即時発生時にこれを実行します。これにより、UTCクロックを使用して、実行する実際の瞬間を決定できます。
someの場合、次の5つのオカレンスや次のすべてのオカレンスなど、次のいくつか（または多く）のインスタンスも投影することができます。年。 （この部分は、アプリケーションの要件に非常に固有です。）
夏時間 の遷移時に発生する発生に対して何をすべきかについての戦略（固定または構成可能）を用意します。
「スプリングフォワード」遷移の場合、発生が存在しない可能性があるローカル時刻が欠落しているギャップがあります。たとえば、米国太平洋時間では、現地時間の午前2時に実行するようにスケジュールされた毎日のタスクは、2014年3月9日には存在しません。ほとんどの場合、その時間を節約量（通常は1時間）だけ進める必要があります。 ）したがって、その日の午前3時に実行されますが、次のインスタンスでは午前2時に実行に戻ります。 （ただし、これに対して別の戦略が必要になる可能性は十分にあります。）
「フォールバック」遷移では、オカレンスが存在する可能性がある場合に重複したローカル時間の重複がありますtwice。たとえば、米国太平洋時間の場合、午前1時に実行するようにスケジュールされた毎日のタスクは、2014年11月2日に実行される可能性のある2つの時刻になります。ほとんどの場合、first1:00 AM PDTの発生と同じ日付の1:00 AM PSTの次の発生をスキップします。 （ただし、もう一度might2番目のオカレンスで実行する、または両方で実行するなど、別の戦略が必要な場合があります。
タイムゾーンデータを更新する必要がある場合は、すべての発生UTC時間をrecalculateする準備をしてください。 IANA/Olson TZDB は、世界の政府がタイムゾーンのオフセットと夏時間のルールについて常に気を変えているため、毎年複数の更新を発行しています。 将来の特定の期間については、ルールが変更されないと想定することはできません。
必ずタイムゾーンデータリリースの アナウンスを購読 し、それらをシステムやアプリケーションに適用するプロセスを用意してください。
従来の企業環境では、これはITの責任である必要があります。運用スタッフ。
環境によっては、
tzdatalinuxパッケージの更新、 Java JREまたはtzupdater 、またはその他のチャネルを介してこのデータを取得している可能性があります。 PHP用のtimezonedb PECLパッケージ など、多くの場合、環境固有の場合もあれば、プログラミングプラットフォーム固有の場合もあります。Microsoftには独自のタイムゾーンデータがあります。 Windowsでは、.NETの
TimeZoneInfoを使用している場合（たとえば）、このデータを使用しています。更新は here から行われ、Windows Updateを介して自動的にプッシュされるので、いつ更新する必要があるかを知るために、更新に注意する必要があります。
すべてが理解されたので、isがまだUTCだけでスケジュールするシナリオであり、それはの場合です[〜＃〜]絶対[〜＃〜]将来のイベント。例：
X時間ごとまたはX分ごとに実行されるジョブ。
日の出の開始時刻と終了時刻、またはその他の天文現象。
機密情報を事前に決められた時間に他の当事者に送信する場合など、時間に敏感なセキュリティウィンドウ。
Windowsタスクスケジューラ
Windowsは必ずしも正しいことをしているわけではありません。トリガーの定義方法に注意してください。
「タイムゾーン間で同期する」というチェックボックスをオンにすると、タスクはUTCのみによってスケジュールされます。 （すべての時間は引き続きローカル時間として表示されますが、storedUTCとして表示されます。）これは、以前に「絶対」イベントと呼んだものです。
このチェックボックスをオフのままにすると、コードが実行されているコンピューターのローカルタイムゾーンが使用されます。時間帯を指定するオプションはありません。そのため、これはIMHOの実装としてはあまり適していません。
それがDSTの動作であるかどうかは正確にはわかりませんが、実験して、それについてご連絡します。それはおそらく私が上記で説明したことを行いますが、必ずしもそうではありません。
SQLエージェント
SQLエージェントスケジューラは、ローカルサーバーの時間を使用できるonlyという点でさらに悪いです。繰り返しになりますが、タイムゾーンは指定できません。UTCも指定できません。
requested でしたが、受け入れられませんでした。
気にしないことで、一般的に。
「タスクが2回実行された場合はどうなりますか？」
通常は問題にならないので、何もする必要はありません。それが問題になる場合、最も簡単な解決策は、夏時間の変更によって影響を受ける時間外にジョブを移動することです。
お気づきのとおり、午前1時から午前2時までの時間は夏時間の終わりに繰り返されます。逆の変更が発生すると（DSTの開始時）、午前2時から午前3時までの時間は発生しません（ジョブは実行されません）。あなたの最良の選択肢は
- uTCまでジョブスケジュールを実行する
- 切り替え外の時間にジョブを実行する（12:59 AMまたは3AM）