PostgreSQLはTZ環境変数を使ったPOSIX標準ルールに沿って記述された時間帯指定を受け入れることができます。
POSIX時間帯の指定は複雑な実世界の時間帯の歴史を扱うには不足しているところもありますが、それを利用する理由があることもあります。
POSIX時間帯の指定には以下の形式があります。
STDoffset[DST[dstoffset] [ ,rule] ]
(可読性のためにフィールド間にスペースを表示していますが、実際にはスペースは使用されません。) フィールドは以下の通りです。
STDは標準時間に使用される時間帯の略称です。
offsetはUTCから標準時間のオフセットです。
DSTは夏時間に使用される略称です。
このフィールドと以下のフィールドが省略された場合、時間帯は夏時間のルールを適用しない固定されたUTCからのオフセットを使用します。
dstoffsetはUTCからの夏時間のオフセットです。
このフィールドは通常は省略されます。このため、デフォルトでは標準時間の offsetより１時間短くなりますが、これは通常は正しい動作です。
以下に記載するように、ruleは夏時間が有効な場合のルールを定義します。
この構文では、時間帯の省略形はESTのような文字列か、<UTC-05>のような角括弧で囲った任意の文字列にすることができます。
ここで与えられた省略形は出力にのみ、中でも一部のタイムスタンプの出力フォーマットにのみ使われることに注意してください。
タイムスタンプの入力で認識される時間帯の省略形はB.4の中で説明されているように決定されます。
オフセットのフィールドはUTCからの差を時間、オプションで分、秒で指定します。
オフセットはhh[:mm[:ss]]のフォーマットで、オプションで先頭に符号をつけることができます(+ もしくは -)。
正の符号はグリニッジよりも西の時間帯に使用されます。(これは他のPostgreSQLで使われているISO-8601の規定とは反対であることに注意してください。)
hhは１桁もしくは２桁です。mmとssを使う場合は２桁でなければなりません。
サマータイム変換のruleには以下のフォーマットがあります。
dstdate[/dsttime],stddate[/stdtime]
(前述の通り、実際にはスペースを含めるべきではありません)
夏時間の開始時刻は、dstdateとdsttimeフィールドが定義し、標準時間の開始時刻はstddateとstdtimeで定義します。
(特に赤道より南の時間帯では前者は後者より年の後半になることもあります。)
日付フィールドには以下のような形式があります。
n単純な整数は年の日を示し、0から364、閏年の場合は365までを数えます。
Jn
この形式ではnは1から365までを数え、2月29日は存在したとしても数えません。
(このように、2月29日の変換が発生する場合はこの方法では指定できません。
しかし、2月以降は、うるう年でもそうでなくとも同じ数になります。 このため、この形式は特定のある日に変換する場合、通常、単純な整数型の形式を利用するよりも有用です。)
Mm.n.d
この形式は同じ月の同じ曜日にいつも発生する変換を指定します。
mは1から12までの月を指定します。
nはnで指定された週のd番目の日を指定します。
nは数字の1から5で、5の場合はその月の最後の週を意味します(4番目か５番目の週になる可能性があります)。
dは数字の0から6で、0は日曜日を指します。
例えば、M3.2.0は「3月の第２日曜日」を意味します。
M形式は多くの一般的な夏時間の変換法を記述するのに十分です。
しかし、夏時間変換法の変化を扱う変数は無いため、実際には、過去のデータを名前付き時間帯(IANA時間帯のデータベースにある)で配置するためには、過去のタイムスタンプを変換する必要があります。
変換ルール中の時間フィールドは符号を含めることができない点を除いて、先に記載したオフセットのフィールドと同じ形式を持っています。
これらのフィールドは他の時間への変換が発生した時の現在のローカル時間を定義します。
省略された場合、デフォルトは02:00:00です。
夏時間の短縮系が与えられ、ruleフィールド変換が省略されている場合、PostgreSQLはIANA時間帯のデータベースの中にあるposixrules ファイルを確認して変換時間を決定することを試みます。
このファイルは時間帯のエントリと完全に同じ形式を持ちますが、UTCからのオフセットではなく、その変換時点のルールが使用されます。
通常、このファイルはUS/Easternファイルと同じ内容を持つため、POSIXスタイルの時間帯指定はアメリカ合衆国の夏時間のルールに従います。
必要な場合は、posixrulesファイルを置き換えることでこの挙動を調整することができます。
posixrulesファイルを確認する機能はIANAによって非推奨とされており、将来的に取り去られる可能性があります。
この機能が無くなる前に修正されそうに無い不具合の一つは、2038年以降の日付にDSTのルールを適用することを失敗していることです。
posixrulesが存在しない場合、代替の動作には2020年のアメリカ合衆国の習慣と照合されるM3.2.0,M11.1.0(3月の第2日曜日に夏時間に切り替わり、11月の第1日曜日に戻ります。両方の変換はその時進んでいる時間の午前2時に行われます)が使用されます。
例えば、CET-1CEST,M3.5.0,M10.5.0/3は(2020年時点の)パリの現時点の時計方法を表しています。
この指定では、標準時間はCETという略語を持ち、UTCより１時間(東)進んでいます。また、夏時間には、CESTという略語を持ち、暗黙的にUTCより２時間進んでいます。夏時間は3月の最終日曜のAM2時に始まり、10月の最終日曜日の3AM CESTに終わります。
4つの時間帯名、EST5EDT、CST6CDT、MST7MDT、PST8PDTはPOSIXゾーンの指定に見えます。
しかし、(歴史的な理由で)IANA時間帯データベースにこれらの名前が記録されているため、実際には名前付き時間帯として扱われます。
これの実際の影響は、明白なPOSIX仕様でも一致するposixrulesファイルがない場合には、これらのゾーン名は有効な歴史的なアメリカ合衆国の夏時間の変換を提供することです。
ゾーンの省略形は妥当性をチェックされていないため、POSIX形式の時間帯指定はスペルミスしやすいことに注意してください。
例えば、SET TIMEZONE TO FOOBAR0は動作しますが、実質的にシステムはUTCの特殊な省略形を使用します。