ここには防弾ソリューションはありません。
私の最初のアドバイス：サーバーのデフォルトのタイムゾーンに依存しないでください。
2番目のアドバイス：timestampから選択してください -timestamptz データの（優勢な）セマンティクスによる。
詳細：PostgresSQLには2つのタイムスタンプバリアントがあり、紛らわしい名前が TIMESTAMP WITHOUT TIMEZONE (timestamp)です。 およびTIMESTAMP WITH TIMEZONE (timestamptz) 。実際、どちらでもない タイムゾーンもオフセットも保存します。両方のデータ型は同じ幅（4バイト）を占め、それらの違いは微妙です-さらに悪いことに、それらを完全に理解しておらず、サーバーがタイムゾーンを変更すると、あなたを噛む可能性があります。私の正気のルールセットは次のとおりです：
-
TIMESTAMP WITH TIMEZONE (timestamptz)を使用します 主に「物理的」時間に関連するイベントを保存するため 、主にevent 1かどうかのクエリに関心があるevent 2の前でした （タイムゾーンに関係なく）、または時間間隔の計算（「物理単位」、たとえば秒。「市民」単位ではなく、日-月など）。典型的な例は、レコードの作成/変更時間です。これは通常、「タイムスタンプ」という言葉が意味するものです。 "。 -
TIMESTAMP WITHOUT TIMEZONE (timestamp)を使用します 関連情報が「常用時」であるイベントを保存するため （つまり、フィールド{year-month-day hour-min-sec}全体として）、クエリにはカレンダーの計算が含まれます。この場合、ここには「現地時間」、つまり、指定されていない（無関係、暗黙、または別の場所に保存されている）タイムゾーンを基準にした日時のみを保存します。
2番目のオプションを使用すると、たとえば「「2013-01-20」日に発生したすべてのイベント」（対応する各地域/国/タイムゾーン）のクエリが簡単になりますが、「参照イベントの前に（物理的に）発生しました」（同じタイムゾーンにあることがわかっている場合を除く）。選択します。
完全なものが必要な場合は、どちらも十分ではありません。タイムゾーンまたはオフセットを追加のフィールドに保存する必要があります。数バイトを浪費するが、クエリに対してより効率的になる可能性がある別のオプションは、両方のフィールドを格納することです。
この回答 。