まず、現代の用語では、GMTではなくUTCと言う必要があることを認識してください。 UTCがより正確に定義されていることを除いて、これらはほとんど同等です。 GMTという用語を予約して、UTC+0のオフセットを持つ冬季に有効な英国のタイムゾーンの部分を指します。
今あなたの質問に。 UTCは、必ずしもすべての日付と時刻の値を格納するための最良の方法ではありません。 過去で特に効果的です イベント、または将来の絶対 イベントですが、将来のローカルにはあまり効果がありません イベント-特に将来の定期的な イベント。
この
もちろん、ただすることはできません 世界中のデータを使用している場合は、現地時間を保存します。いくつかの異なるものを保存する必要があります：
- 「08:00」などの定期的なイベントの現地時間
- 「America/New_York」など、現地時間が表されるタイムゾーン
- 繰り返しパターンは、毎日、隔週、毎月第3木曜日など、アプリケーションにとって意味のある形式であれば何でもかまいません。
- 次の即時 UTCの日付と時刻は、予測できる最高のものに相当します。
- 常にではありませんが、将来のイベントUTC日時のリストは、将来の事前定義された期間（必要に応じて、おそらく1週間、おそらく6か月、おそらく1年または2年）を予測します。
最後の2つについては、そのタイムゾーンを担当する政府が何かを変更することを決定した場合、ローカルの日付/時刻に相当するUTCが変更される可能性があることを理解してください。タイムゾーンデータベースは毎年複数回更新されるため、を計画する必要があります。更新のアナウンスを購読する
および
複数のタイムゾーンにまたがるイベントのあらゆる種類のリストを表示する場合は、UTCに相当するものを用意することが重要です。これらは、そのリストを作成するためにクエリする値です。
考慮すべきもう1つのポイントは、DSTフォールバック遷移中に発生する現地時間にイベントがスケジュールされている場合、イベントが最初のインスタンスで発生するか（通常）、2番目のインスタンスで発生するか（場合によっては）を決定する必要があることです。またはその両方（まれに）、必要な場合を除いてイベントが2回発生しないようにするメカニズムをアプリケーションに組み込みます。
簡単な答えを探していた場合-申し訳ありませんが、1つはありません。タイムゾーンを超えて将来のイベントをスケジュールすることは複雑な作業です。
代替アプローチ
何人かの人に、行うテクニックを見せてもらいました。 スケジューリングにUTC時間を使用します。つまり、現地時間で開始日を選択し、それをUTCに変換して保存し、タイムゾーンIDも保存します。次に、実行時に、タイムゾーンを適用して元のUTC時刻を現地時間に変換し、その現地時間を使用して、上記のように元々保存されていたものであるかのように、他の繰り返しを計算します。
この手法は機能します 、欠点は次のとおりです。
-
最初のインスタンスが実行される前に現地時間を変更するタイムゾーンの更新がある場合、スケジュール全体が延期されます。これは、「最初の」インスタンスの過去の時間を選択して、2番目のインスタンスが実際に最初のインスタンスになるようにすることで軽減できます。
-
時刻が実際にユーザーを追跡する必要のある「変動時間」である場合（携帯電話の目覚まし時計など）、元々作成されたゾーンのタイムゾーン情報を保存する必要があります。それはあなたが実行したいゾーンではありません。
-
何のメリットもなく、複雑さが増します。この手法は、タイムゾーンサポートを後付けしようとしているUTCのみのスケジューラを使用している可能性がある状況のために予約しておきます。