タイムゾーン対応アプリを構築しています。テストする必要がある一般的な (およびそれほど一般的ではない) シナリオは何ですか?
私が考えることができる唯一のコーナーケースは DST ですが、私はたくさんのことを見逃していると確信しています.
タイムゾーン対応アプリを構築しています。テストする必要がある一般的な (およびそれほど一般的ではない) シナリオは何ですか?
私が考えることができる唯一のコーナーケースは DST ですが、私はたくさんのことを見逃していると確信しています.
私の頭の上から
タイムゾーンは時系列です: つまり、ある瞬間の現地時間を取得してどこかに保存すると、今日のタイムゾーン情報を使用していることになります。明日までに、この情報は変更されている可能性があり、保存されたインスタントは別の方法で解釈される可能性があります。これを解決するには、記述したいイベントまたは瞬間とともにタイムゾーン情報を手元に保存することを検討してください。
日付と時刻は観察です: これは、その時点で有効なタイムゾーンに関係なく、ローカル時間でその時点をエンコードし、観察時に変換できることを意味します。1 月 1 日の午前 2 時は、今日の基準点より 4 日と 3 時間進んでいる可能性があります。しかし、1 月 1 日の午前 2 時に、まったく同じ基準点が 4 日と 2 時間前にしか見えない場合があります。そのため、異なる時間の基準点間の経過時間を変換する際には注意が必要です。特に、タイマー (N
秒単位) を設定した場合、それがまだ時々イベントに一致するかどうかを再計算する必要がある場合があります。
タイムゾーンは地域的です。つまり、同じタイムゾーン オフセットを持つすべての日時を同じものとして扱うことはできません。特に、北半球と南半球で DST を観測する場所は、1 年のうちしばらくは一致する可能性がありますが、残りの年は完全に同期していません。
現地時間で指定された日付と時刻は、存在する必要がないか、複数回存在する可能性があります。DST の例を示しました。DST の切り替え時に、切り替え前と切り替え後に 1 回、2 回の逆時間が発生するため、そのためのフラグが必要になる場合があります。同様に、DST スイッチフォワードは時間をスキップします。ただし、DST は唯一の例ではありません。国際日付変更線に近い一部の地域では、日付変更線の左側または右側に決定され、その結果、1 日が欠けているか、1 日が 2 回繰り返されています。