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 缩写。
如果您在文档中发现任何不正确、与您使用特定功能的经验不符或需要进一步澄清的内容，请使用此表单报告文档问题。