PostgreSQL 可以接受根據 TZ 環境變數的標準規則編寫的時區規範。POSIXPOSIX 時區規範不足以處理真實世界時區歷史的複雜性，但有時有理由使用它們。POSIXPOSIX 時區規範的格式如下：
STDoffset[DST[dstoffset][rule]]
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 指定由 d 識別的星期幾的第 n 次出現。n 是介於 1 和 4 之間的數字，或 5 表示該月中該星期幾的最後一次出現（可能是第四次或第五次）。d 是介於 0 和 6 之間的數字，0 表示星期日。例如，M3.2.0 表示“三月的第二個星期日”。
M 格式足以描述許多常見的日光節約時間轉換規則。但請注意，這些變體都無法處理日光節約時間法的變更，因此實際上，為了正確解釋過去的時間戳記，必須儲存命名時區的歷史資料（在 IANA 時區資料庫中）。
轉換規則中的時間欄位與先前描述的時差欄位格式相同，但它們不能包含符號。它們定義變更為另一時間時的目前當地時間。如果省略，則預設為 02:00:00。
如果提供了日光節約時間的縮寫，但省略了轉換rule欄位，則預設行為是使用規則M3.2.0,M11.1.0，這對應於截至2020年的美國實踐（即，在三月的第二個星期日往前撥快，在十一月的第一個星期日往後撥慢，兩次轉換都發生在當地時間凌晨2點）。 請注意，此規則無法為2007年之前的年份提供正確的美國轉換日期。
例如，CET-1CEST,M3.5.0,M10.5.0/3描述了巴黎目前（截至2020年）的計時慣例。 此規範表示標準時間的縮寫為CET，並且比UTC快（東）一小時； 日光節約時間的縮寫為CEST，並且隱含地比UTC快兩小時； 日光節約時間從三月的最後一個星期日凌晨2點CET開始，到十月的最後一個星期日凌晨3點CEST結束。
四個時區名稱EST5EDT、CST6CDT、MST7MDT和PST8PDT看起來像是POSIX時區規範。 但是，由於（歷史原因）IANA時區資料庫中存在這些名稱的文件，因此它們實際上被視為已命名的時區。 實際的含義是，即使普通的POSIX規範無法產生有效的美國日光節約轉換，這些時區名稱也將產生有效的美國日光節約轉換歷史。
應該警惕的是，很容易拼錯POSIX風格的時區規範，因為沒有檢查時區縮寫的合理性。 例如，SET TIMEZONE TO FOOBAR0將起作用，使系統有效地使用一個相當奇特的UTC縮寫。
如果您在文件中發現任何不正確、與您使用特定功能的經驗不符或需要進一步澄清的地方，請使用此表格來報告文件問題。