これは難しい質問です。実際、SQL標準のように思えるほど難しいので、そこにある主要なデータベースのほとんどは、それらの実装の手がかりを持っていません。
すべての日時をUTCに変換すると、レコード間の比較が簡単になりますが、タイムゾーン情報が破棄されます。つまり、レコードを使用して計算したり(たとえば、保存された日時に8か月を追加したり)、保存されたタイムゾーンでレコードを取得したりすることはできません。したがって、素朴なアプローチは出ています。
タイムスタンプ(たとえば、postgresのタイムゾーンを持つタイムスタンプ)に加えてUTCからのタイムゾーンオフセットを保存することで十分なように見えますが、DSTにより、異なるタイムゾーンで1年のある時点で同じオフセットを持ち、6か月後に異なるタイムゾーンを持つことができます。 。たとえば、ニューヨークとチリの両方を現在(8月)UTC-4に設定できますが、11月4日以降はニューヨークがUTC-5になり、チリ(9月2日以降)がUTC-3になります。したがって、オフセットだけを保存しても、正確な計算を行うことはできません。上記の素朴なアプローチのように、それも情報を破棄します。
代わりにタイムスタンプ付きのタイムゾーン識別子(例:America / Santiago)を保存するとどうなりますか?これにより、チリの日時とニューヨークの日時を区別できるようになります。しかし、これではまだ十分ではありません。有効期限を保存している場合、たとえば6か月後の深夜0時に、DSTルールが変更された場合(残念ながら政治家が好むように)、タイムスタンプが間違っており、代わりに午後11時または午前1時に有効期限が発生する可能性があります。これは、アプリケーションにとって大きな問題になる場合とそうでない場合があります。したがって、タイムスタンプを使用すると、情報も破棄されます。
本当に正確であるためには、ローカルの日時を(たとえば、タイムゾーンに対応していないタイムスタンプタイプを使用して)タイムゾーン識別子とともに保存する必要があるようです。より高速な比較をサポートするために、使用するタイムゾーンデータベースが更新されるまでUTCバージョンをキャッシュし、キャッシュされた値が変更されている場合は更新することができます。つまり、2つの単純なタイムスタンプタイプに加えて、タイムゾーン識別子と、タイムゾーンデータベースが変更されたかどうかをチェックし、キャッシュされたタイムスタンプに対して適切な更新クエリを実行するある種の外部cronジョブになります。
それは正確な解決策ですか?それとも私はまだ何かが足りないのですか?もっと上手くできますか?
MySQL、SQL Server、Oracle、PostgreSQL、およびTIMESTAMP WITHTIMEZONEを処理するその他のDBMSのソリューションに興味があります。