B.5. Указание часовых поясов в стиле POSIX
PostgreSQL может воспринимать указание часового пояса, записанное по правилам стандарта POSIX, в соответствии с которыми, в частности, задаётся переменная окружения TZ
. Указания часовых поясов в стиле POSIX не удовлетворяют всем условиям, продиктованным сложной историей часовых поясов в реальном мире, но иногда использование этих указаний бывает оправданным.
Указание часового пояса в стиле POSIX выглядит так:
STD
смещение
[DST
[смещение_летнего_времени
] [ ,правило
] ]
(Для наглядности между полями добавлены пробелы, но в реальном указании их не должно быть.) В нём содержатся следующие поля:
STD
— аббревиатура, используемая для стандартного часового пояса.смещение
— стандартное смещение пояса от UTC.DST
— аббревиатура часового пояса при переходе на летнее время. Если это поле и следующие за ним опущены, для часового пояса будет использоваться фиксированное смещение от UTC без учёта перехода на летнее время.смещение_летнего_времени
— смещение часового пояса от UTC при переходе на летнее время. Это поле обычно опускается, так как по умолчанию это смещение равно стандартномусмещению
минус один час, что практически всегда имеет место на практике.правило
— определяет, как должен учитываться переход на летнее время, в соответствии с представленным ниже описанием.
В этой записи аббревиатура часового пояса может задаваться набором букв, например EST
, или произвольной строкой, заключённой в угловые скобки, например <UTC-05>
. Заметьте, что показанные здесь аббревиатуры используются только при выводе и только в некоторых выходных форматах. Распознаваемые во входных значениях даты/времени аббревиатуры часовых поясов описаны в Разделе B.4.
В полях смещений задаётся сдвиг от UTC в часах и, возможно, минутах и секундах. Они имеют формат чч
[:
мм
[:
сс
]] и могут содержать спереди знак (+
или -
). Положительный знак имеют часовые пояса к западу от Гринвича. (Заметьте, что это противоположно соглашению ISO-8601, используемому в других областях PostgreSQL.) Компонент чч
может содержать одну или две цифры, а мм
и сс
(если они задаются) должны состоять ровно из двух цифр.
Поле, задающее правило
перехода на летнее время, имеет следующий формат:
дата_перехода
[/
время_перехода
],
дата_возврата
[/
время_возврата
]
(Как и ранее, реальное указание не должно содержать пробелы.) Поля дата_перехода
и время_перехода
определяют момент перехода на летнее время, а поля дата_возврата
и время_возврата
определяют дату возврата к поясному времени. (В некоторых регионах, в частности, в Южном полушарии, вторая дата в календаре может предшествовать первой.) Даты могут задаваться в одном из следующих форматов:
n
Простое целое, обозначающее день года, с нумерацией от нуля до 364, или 365 в високосном году.
J
n
В этой записи
n
обозначает номер дня от 1 до 365, а 29 февраля пропускается, даже когда фактически присутствует. (Таким образом, смены часового пояса, происходящие 29 февраля, в этой записи выразить нельзя. Однако после февраля дни имеют одинаковые номера и в обычные, и в високосные годы, так что эта запись обычно полезнее тем, что позволяет выразить одним числом фиксированную дату перевода часов.)M
m
.
n
.
d
Эта форма задаёт дату перехода, которая всегда назначается в определённый месяц и день недели. Здесь
m
обозначает номер месяца от 1 до 12, аn
— номер повторения в этом месяце дня недели, заданного полемd
. В качествеn
может задаваться число от 1 до 4 либо число 5, выбирающее последнюю дату с заданным днём недели в этом месяце (она может быть фактически четвёртой или пятой). В качествеd
задаётся число от 0 до 6, обозначающее день недели (0 — воскресенье). Например, записьM3.2.0
расшифровывается как «второе воскресенье марта».
Примечание
Для описания многих существующих правил перехода на летнее время обычно достаточно формата M
. Но заметьте, что ни одна из этих вариаций не позволяет описать изменения правил перевода часов. Поэтому на практике для правильной интерпретации значений времени, относящихся к прошлому, необходимы исторические данные, хранящиеся в привязке к именованным часовым поясам (в базе данных IANA с информацией о часовых поясах).
Поля времени в описании правила перехода имеют тот же формат, что и поля смещений, описанные ранее, за исключением того, что в них не может быть знака. Они определяют текущее местное время, в которое производится перевод часов. По умолчанию временем перевода часов считается 02:00:00
.
Если задаётся аббревиатура для летнего времени, но правило
перехода не задано, в качестве правила по умолчанию используется M3.2.0,M11.1.0
, что соответствует существующему в США в 2020 г. порядку. То есть часы переводятся на летнее время во второе воскресенье марта, а на зимнее — в первое воскресенье ноября, в два часа по действующему времени. Заметьте, что это правило даёт правильные даты для США только с 2007 г.
Например, запись CET-1CEST,M3.5.0,M10.5.0/3
отражает действующую в 2020 г. практику перевода часов в Париже. Это указание говорит, что стандартное поясное время имеет аббревиатуру CET
и оно смещено на час вперёд (к востоку) от UTC; летнее время имеет аббревиатуру CEST
и смещено вперед от UTC на два часа (это определяется неявно). Часы переводятся на летнее время в последнее воскресенье марта в 2:00 CET, а на зимнее — в последнее воскресенье октября в 3:00 CEST.
Названия четырёх часовых поясов EST5EDT
, CST6CDT
, MST7MDT
и PST8PDT
выглядят как определяющие часовые пояса в стиле POSIX, но в реальности по историческим причинам они воспринимаются как имена часовых поясов, наравне с другими, так как в базе данных IANA есть файлы с такими именами. Практическое следствие этого состоит в том, что для данных имён может быть получена историческая информация о действовавших правилах перехода на летнее время в США, которую не может дать обычное указание в стиле POSIX.
Имейте в виду, что ошибиться в указании часового пояса в стиле POSIX очень легко, так как адекватность аббревиатуры никак не проверяется. Например, команда SET TIMEZONE TO FOOBAR0
выполнится без ошибки, и система в итоге будет использовать весьма своеобразную аббревиатуру для UTC.