PostgreSQL 可以接受根據POSIX標準關於 TZ 環境變數的規則編寫的時區規範。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 指定由 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 年的美國做法（即，3 月的第二個星期日春季調快，11 月的第一個星期日秋季調回，兩次轉換都在當地時間凌晨 2 點發生）。請注意，此規則不提供 2007 年之前美國轉換日期的正確資訊。
例如，CET-1CEST,M3.5.0,M10.5.0/3 描述了巴黎當前（截至 2020 年）的時間保持實踐。此規範表示標準時間縮寫為 CET，比 UTC 快一小時（東）；夏令時縮寫為 CEST，隱式比 UTC 快兩小時；夏令時於 3 月的最後一個星期日凌晨 2 點 CET 開始，並於 10 月的最後一個星期日凌晨 3 點 CEST 結束。
四個時區名稱 EST5EDT、CST6CDT、MST7MDT 和 PST8PDT 看起來像是 POSIX 時區規範。然而，它們實際上被視為命名時區，因為（出於歷史原因）IANA 時區資料庫中存在以這些名稱命名的檔案。這實際意味著這些時區名稱將產生有效的歷史美國夏令時轉換，即使普通的 POSIX 規範不會。
應該警惕，POSIX 風格的時區規範很容易拼寫錯誤，因為沒有對時區縮寫合理性進行檢查。例如，SET TIMEZONE TO FOOBAR0 將起作用，使系統實際上使用了一個相當奇特的 UTC 縮寫。
如果您在文件中發現任何不正確、與您使用特定功能的經驗不符或需要進一步澄清的內容，請使用此表單報告文件問題。