UTC（GMT + 0）タイムスタンプを含むデータベースがあります。ここに問題があります：それらはインディアナ州で起こった請求活動を指します。
ご存知かもしれませんが、インディアナ...
- 2006年以前は、夏時間はまったく観測されていませんでした（州のほとんどは、一年中ESTでした）。
- 2006年にESTを維持するために投票しましたが、米国の他の地域との夏時間の監視を開始しました
- 2007年に規則を改訂しました。米国連邦政府は、開始規則と終了規則が変更されるように夏時間を改訂しました
このデータベースのタイムスタンプは政府の請求活動を参照しているため、監査の正確性を維持するために、UTCタイムスタンプを過去に正確な現地時間として報告する必要があります。したがって、インディアナに固有に適用される3つのシナリオがあります。2006年より前のタイムスタンプは2006年から2007年までのタイムゾーンルールとは完全に異なるタイムゾーンルールのセットを使用し、2007年以降のタイムスタンプはさらに別の完全に異なるタイムゾーンルールのセットを使用します。このデータベースにはインディアナ以外のロケールのアクティビティが含まれているため、事態はさらに複雑になることが想像できます。
JavaCalendarおよびTimeZoneAPIには、プログラマーが複数のタイムゾーンルールのセットを使用してオブジェクトを作成できるクラスが含まれていないため、特定の該当するタイムゾーンの場合、UTCタイムスタンプを履歴的に正確な現地時間に正しくマッピングするために使用することはできません。ルールは変わります。
タイムゾーンルールを変更して、ロケールで歴史的に正確な現地時間にマッピングする問題に対処する方法を考えました...
データベースを更新して、UTCタイムスタンプを現地時間オフセットおよび夏時間オフセットとともに保存できるようにすることができます。ここでの問題は、データベースのサイズが少し大きくなり、既存のデータベースが大きい場合、すべてのテーブルを更新するには、オフラインのメンテナンスサイクルを延長する必要がある場合があることです。
その特定のタイムスタンプに適切な特定のTimeZoneオブジェクトが各タイムスタンプとともに保存されるように、データベースを更新できます。TimeZoneオブジェクトはかなり軽量だと思いますが、これは上記よりも柔軟性がありますが、タイムスタンプごとにオブジェクトを永続化する必要があるため、あまり望ましくありません。
対象のロケールの歴史的に正確なルールのデータベースから適切なTimeZoneオブジェクトを構築するカスタムAPIを開発できます。このソリューションは、前の2つのソリューションで増加したストレージ要件を、追加の処理の必要性に置き換えます。表示する必要のあるすべてのタイムスタンプは、新しいオブジェクトを作成すること、または少なくともオブジェクトプールから適切なオブジェクトとペアリングすることを意味します。さらに、タイムゾーンデータベースの作成と管理を意味します。
JavaTimeおよびCalendarAPIの制限により、この問題の洗練された解決策を見つけるのが本来よりも非常に困難になっています（たとえば、既存のSimpleTimeZoneオブジェクトをクエリして、それが従う夏時間のルールをいくつか記述せずに尋ねることはできません。本当に厄介なコード）。
他の誰かが以前にこのような状況に対処したことがあるかどうか、そして彼らがそれをどのように処理したかを尋ねたいと思います。