Postgresql 中文操作指南

B.5. POSIX Time Zone Specifications #

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

POSIX 时区规范有以下形式

STD offset [ DST [ dstoffset ] [ , rule ] ]

（为提高可读性，我们在字段之间显示空格，但实际中不应使用空格）。字段如下：

在此语法中，时区缩写可以是字母字符串，例如 EST，或用尖括号括起来的任意字符串，例如 <UTC-05>。请注意，此处提供的时区缩写仅用于输出，即使是那样也仅用于某些时间戳输出格式。正如在 Section B.4 中解释的那样，识别时间戳输入中的时区缩写的过程是确定的。

偏移量字段指定与 UTC 的小时差，还可以选择指定分钟和秒。它们的格式为 hh [ :_mm[:_ss ]，可以选择在前面加一个符号（ + 或 - ）。UTC 以西的时区使用正号。（请注意，这与 PostgreSQL 中其他地方使用的 ISO-8601 符号约定相反。） hh 可以有一位或两位数字；如果使用了 mm 和 ss ，则它们必须有两位数字。

夏令时转换 rule 的格式为

dstdate [ / dsttime ] , stddate [ / stdtime ]

（如前所述，实际情况下不应包含空格。）dstdate 和 dsttime 字段定义日光节约时间开始的时间，而 stddate 和 stdtime 定义标准时间开始的时间。（在某些情况下，尤其在赤道以南的时区中，前者可能晚于后者。）日期字段具有以下格式之一：

  • n

    • 纯整数表示一年中的某一天，从零计数到 364，或在闰年中计数到 365。

  • J__n

    • 在此形式中， 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 表示“3 月的第二个星期日”。

Note

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 点开始，在 10 月的最后一个星期日上午 3 点结束。

四个时区名称 EST5EDT、CST6CDT、MST7MDT 和 PST8PDT 看起来像是 POSIX 时区规范。但是，它们实际上被视为命名时区，因为（由于历史原因）IANA 时区数据库中有这些名称的文件。实际含义是，即使纯 POSIX 规范不这样做，这些时区名称仍将产生有效的美国历史日光节约时间转换。

人们应该小心，很容易拼错 POSIX 样式的时区规范，因为没有检查时区缩写的合理性。例如，SET TIMEZONE TO FOOBAR0 将起作用，使系统有效使用 UTC 的相当特殊的缩写。