The EDB Blog
November 7, 2017

以前の ブログエントリ では、クライアントが元のタイムゾーンで保存された時間を知る必要がある場合、元のタイムゾーンオフセットを別の列に保存することを提案しました。私が取り上げたいこの問題は、いくらか複雑です。

まず、私がselect extract(current_timestampからのタイムゾーン)を使用することを提案する時、ユーザーはデータベースにcurrent_timestampの値も格納していると仮定しました。過去または未来のタイムスタンプをデータベースに格納していた場合、current_timestampの代わりにその値をextractで使用する必要があります。

二番目に、ブログコメントでMiha Vrhovnik氏によって指摘されたように、未来の時間がデータベースに格納され、データが格納されたに未来のタイムゾーン規則が変更されると、事態はより複雑になります。この懸念は机上のものだと思われるかもしれませんが、ロシアは実際、2014年2016年にこのような変更を加えました。

適切な行動を取るには、未来のタイムスタンプを保存している場合は、同じ実測時間を保持したいのか、とあなたは自分自身に問わなくてはなりません。例えば、病院の診察予約を記録していた場合、同じ時刻(実測時間)を反映するように保存された値を調整したいものと考えられます。未来に起きる天文現象を記録していた場合、可視時間が変わっても同じ時間に保つことが望ましいでしょう。デフォルトのタイムゾーン動作を伴うタイムスタンプは、同じ時間に保持します。すなわち天文学的動作を保持します。

タイムゾーンのルール変更後に同じ将来の実測時間を保持するには、タイムゾーンなしでタイムスタンプを格納し、タイムゾーンを別の列に格納する必要があります。現在のタイムゾーンのルールに基づいて時間を計算するには、タイムゾーンなしのタイムスタンプと、各クエリーのタイムゾーン名を組み合わせる必要があります。このような計算を行ったindexesは、タイムゾーン規則が変更された時に、再び索引付けする必要があります。

This method allows the data to adjust to future time zone rule changes by computing the time zone offset on demand, rather than being locked in the time zone rules which were current at the time the data was entered, e.g.:

-- controls the OUTPUT time zone of AT TIME ZONE when passed a WITHOUT TIME ZONE value
SET TIME ZONE 'Europe/Moscow';

-- AT TIME ZONE specifies the time zone for the literal value
SELECT TIMESTAMP WITHOUT TIME ZONE '2012-03-08 09:00:00' AT TIME ZONE 'Europe/Moscow';
        timezone
------------------------
2012-03-08 09:00:00+04

SELECT TIMESTAMP WITHOUT TIME ZONE '2022-03-08 09:00:00' AT TIME ZONE 'Europe/Moscow';
        timezone
------------------------
2022-03-08 09:00:00+03

 

基本的に、未来のタイムゾーンルールが変更された場合、出力時刻は同じになりますが、utcと比較して時間が変わります。例:+03。もちろん、すべてのイベントが同じタイムゾーンにあり、「天文現象に関する行動」を望まない場合は、タイムゾーンの調整は必要ありません。よって、Miha Vrhovnik氏の意見は正しいと言えます。タイムゾーンを使用することは、特にすべてのエントリが同じタイムゾーンにあり、未来のタイムゾーンの変更が可能である場合には、それがもたらす価値よりも、トラブルにつながる可能性が高いことは間違いありません。

Bruce Momjian氏は、EnterpriseDBの上級データベース設計者です。

このポストはもともとBruceの個人的な投稿です。blog

 

 

bruce.momjian's picture

Bruce Momjian is a co-founder of the PostgreSQL Global Development Group, and has worked on PostgreSQL since 1996 as a committer and community leader. He is a frequent speaker and Postgres evangelist and travels worldwide appearing at conferences to help educate the community on the business...