PostgreSQL 教程

Appearance

B.5.POSIX时区规范# ​

PostgreSQL可以接受根据POSIX标准的TZ环境变量规则编写的时区规范。POSIX时区规范不足以处理现实世界时区历史的复杂性，但有时有理由使用它们。

POSIX 时区规范的格式为

STD offset [ 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 使用一个相当奇怪的缩写。