システム全体が「ヨーロッパ/ウィーン」であるにもかかわらず、PostgreSQLが使用するタイムゾーンがGMTであるPostgreSQL 9.2がいくつかインストールされています。私はそれを再確認しましたpostgresql.conf
はnotにtimezone
設定が含まれているため、ドキュメントによれば、システムのタイムゾーンにフォールバックする必要があります。
しかしながら、
# su -s /bin/bash postgres -c "psql mydb"
mydb=# show timezone;
TimeZone
----------
GMT
(1 row)
mydb=# select now();
now
-------------------------------
2013-11-12 08:14:21.697622+00
(1 row)
GMTタイムゾーンがどこから来るのか、ヒントはありますか?システムユーザーにはTZ
が設定されておらず、/etc/timezone
および/etc/timeinfo
は正しく設定されているようです。
# cat /etc/timezone
Europe/Vienna
# date
Tue Nov 12 09:15:42 CET 2013
ヒントはありがたいです、事前に感謝します!
TimeZone
設定のデフォルト値は、リリース9.2で変更されました。
(..)明示的に設定されていない場合、サーバーはこの変数をシステム環境で指定されたタイムゾーンに初期化します。 (...)
(...)組み込みのデフォルトはGMTですが、通常はpostgresql.confでオーバーライドされます。 initdbは、システム環境に対応する設定をそこにインストールします。 (...)
つまり、バージョン9.2より前のバージョンでは、initdb
フェーズでpostgresql.conf
のデフォルト値を設定する必要があります。その値を上書きした場合(おそらく古いバージョンからのアップグレード中に古いpostgresql.conf
をコピーします)、PostgreSQLはデフォルトで "GMT"値を使用します。
あなたのケースの解決策は非常に簡単です、postgresql.conf
のTimeZone
設定を必要な値に変更するだけです:
TimeZone = 'Europe/Vienna'
その後、サービスをreload
する必要があります:
# su - postgres -c "psql mydb -c 'SELECT pg_reload_conf()'"
これで、timestamp with time zone
(またはtimestamptz
)として格納されているすべてのフィールドが正しく表示されるようになります。ただし、timestamp without time zone
(またはtimestamp
)として保存されているすべてのフィールドを手動で修正(更新)する必要があります。
PostgreSQLをアップグレードするすべての人に私が与えるヒントは、古いpostgresql.conf
を新しいクラスターにコピーしないことです(あなたが何をしたかはわかりませんが、それが原因でこの非常に同じ問題が多く見られました)。 initdb
によって生成されたものを取得し、変更を追加するだけです(diff
ツールがこのタスクに役立つ場合があります)。
これの回避策を見つけました。
/ usr/share/zoneinfo /内にシンボリックリンクを作成するlocaltime(または任意の名前)/ etc/localtimeを指すようにする
/usr/share/zoneinfo/localtime -> /etc/localtime
このようにして、最終的にシステムのタイムゾーンを指す一連のリンクを作成します。
/etc/localtime -> /usr/share/zoneinfo/America/Los_Angeles
作成したリンクの名前(私の場合は--localtime)を取得し、postgresql.confの構成アイテムの値として使用します
TimeZone = 'localtime'
postgresqlを再起動し、「SELECT now();」で時刻を確認しますそして「タイムゾーンを表示する」;