何らかの理由で、「タイムゾーン付きの時間」という概念は、多くのユーザーやアプリケーション開発者にとって混乱を招きます。 これは、アプリケーションが多くのタイムゾーンを処理する必要がある場合に、膨大な数の粗さの出現を伴います。 その結果、開発者はアプリケーション内で特別なコードの形式でこのロジックを設計しようとします。その結果、データ処理で当然のhemoを必然的に受け取ります。
タイムゾーンタイプのタイムスタンプを使用しないように呼び出すことを聞いた一般的な誤った理由を次に示します。
- すべてをUTC形式で保存したい。
- リクエストからいくつかの異なるタイムゾーンを取得したくありません。
- タイムゾーンの処理には特別なライブラリを使用します。
- タイムゾーンを保存するためにディスク領域を無駄にしたくありません。
これらの論文はすべて、一時データをデータベースに保存するという原則に対する根本的な誤解から生まれました。
直観的に、 timestampTZは現在およそ次のように格納されていると想定できます。
"2011-06-11 15:53:22 PDT"
つまり、タイムゾーン情報が時刻自体に追加されます。 これは事実とはほど遠い。
代わりに、使用されるタイプ（ タイム ゾーンなしの タイムスタンプまたはタイム ゾーン付きのタイムスタンプ ）に関係なく、すべての一時データはUTC値として保存されます。 違いは記録プロセスにあります。 データタイプにタイムゾーン情報の保存が含まれる場合、データを保存するたびに、UTCのユーザーの現地時間から自動的に変換されます。 ユーザーがデータを要求すると、UTCからユーザーのローカルタイムゾーンに変換されます。
ジョシュがカリフォルニアに住んでいるとしましょう（タイムゾーン「アメリカ/ Los_Angeles」）。 次のような行をテーブルに追加します。
INSERT INTO messages ( user_id, message, left_at )
VALUES ( 3, ' !', '2011-09-27 17:17:25' );
...次に、データを要求したフィラデルフィア（「アメリカ/ニューヨーク」のタイムゾーン）に住むブルースは、次のように表示されます。
user_id | 3
message | !
left_at | 2011-09-27 20:17:25-04
...そして、スウェーデンに住むマグナス （「ヨーロッパ/ストックホルム」）は、次のように受け取ります。
user_id | 3
message | !
left_at | 2011-09-28 02:17:25+02
データはUTCとして保存されますが、各ユーザーに表示されるものは現地時間に関連付けられています。
タイムゾーンのないタイムスタンプは、すべてのタイムデータが同じタイムゾーンに属していると仮定して、単に変換を実行しません。
ほとんどのプログラミング言語では、追加のソフトウェアレイヤーに依存するのではなく、PostgreSQLサーバーの良心に基づいて一時データの処理を残すことは理にかなっています。 完全な責任を負って、次のことを宣言できます。「Postgresでの一時データのサポートは、当然のことながら参照です。 また、全体的に、PHP、Python、またはPerlのライブラリよりも信頼性が高く最新です。」 また、PostgreSQLが夏時間/冬時間への切り替えの問題に対処していることも注目に値します。
さらに重要なことは、 timestampTZを使用すると、ユーザーのタイムゾーンでデータを表示するためのアプリケーションコードの作成について心配する必要がないことを意味します。 代わりに、ユーザーセッションのTIMEZONEパラメーターを設定するだけで、適切なタイムゾーンで時刻データが自動的に表示されます。
もちろん、タイムゾーン情報を保存しない理由はいくつかあります。
- ドライバーまたはORMはタイムゾーンをサポートしていません（ただし、これは新しいタイムゾーンを支持する議論になる場合があります）。
- また、コードは適切なタイムゾーンサポートなしでDBMSで動作するはずです。
- 日付列でテーブルをパーティション化し、絶対値が必要です。
- データベースが複数のタイムゾーンで使用されることはありません。
ただし、これらの理由のいずれも当てはまらない場合は、 timestampTZタイプを使用する必要があります。
ところで、Alvaro Herreraは現在、データを変更したクライアントアプリケーションのタイムゾーンを保存できる新しい追加のデータ型の作成に取り組んでいます。 このタイプは狭い円で需要があり、標準の時間タイプに代わるものではありません。