PostgreSQL 可以接受根据POSIXTZ 环境变量的标准规则编写的时区规范。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普通整数表示一年中的某一天，从零计数到 364，或在闰年中计数到 365。
Jn在此形式中，n 从 1 计数到 365，即使 2 月 29 日存在也不予计算。（因此，无法以此方式指定在 2 月 29 日发生的转换。然而，任一日后的日子在闰年中和非闰年中都是相同的数字，所以此形式通常比普通整数形式更适用于固定日期上的转换。）
Mm.n.d此表单指定始终在相同月份和相同星期日期间发生的转换。m 指定月份，从 1 到 12。n 指定 d 指定的星期日期间的第 n 次出现。n 是介于 1 到 4 之间的数字，或者 5 表示该星期日期间在该月份的最后一次出现（可能是第四或第五次）。d 是介于 0 到 6 之间的数字，其中 0 表示星期日。例如，M3.2.0 表示““3 月的第二个星期日””。
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 使用一个相当奇怪的缩写。
如果您在文档中发现任何不正确、与特定功能的体验不符或需要进一步澄清的地方，请使用此表格报告文档问题。