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 в високосном году.
JnВ этой записи
nобозначает номер дня от 1 до 365, а 29 февраля пропускается, даже когда фактически присутствует. (Таким образом, смены часового пояса, происходящие 29 февраля, в этой записи выразить нельзя. Однако после февраля дни имеют одинаковые номера и в обычные, и в високосные годы, так что эта запись обычно полезнее тем, что позволяет выразить одним числом фиксированную дату перевода часов.)Mm.n.dЭта форма задаёт дату перехода, которая всегда назначается в определённый месяц и день недели. Здесь
mобозначает номер месяца от 1 до 12, аn— номер повторения в этом месяце дня недели, заданного полемd. В качествеnможет задаваться число от 1 до 4 либо число 5, выбирающее последнюю дату с заданным днём недели в этом месяце (она может быть фактически четвёртой или пятой). В качествеdзадаётся число от 0 до 6, обозначающее день недели (0 — воскресенье). Например, записьM3.2.0расшифровывается как «второе воскресенье марта».
Примечание
Для описания многих существующих правил перехода на летнее время обычно достаточно формата M. Но заметьте, что ни одна из этих вариаций не позволяет описать изменения правил перевода часов. Поэтому на практике для правильной интерпретации значений времени, относящихся к прошлому, необходимы исторические данные, хранящиеся в привязке к именованным часовым поясам (в базе данных IANA с информацией о часовых поясах).
Поля времени в описании правила перехода имеют тот же формат, что и поля смещений, описанные ранее, за исключением того, что в них не может быть знака. Они определяют текущее местное время, в которое производится перевод часов. По умолчанию временем перевода часов считается 02:00:00.
Если задаётся аббревиатура для летнего времени, но правило перехода не задано, PostgreSQL пытается определить время перехода, обратившись к файлу posixrules, относящемуся к базе данных часовых поясов IANA. Этот файл позволяет определить полное указание часового пояса, но из этого указания берутся только правила перевода часов, но не смещения от UTC. Как правило, содержимое этого файла совпадает с содержимым файла US/Eastern, поэтому указание часового пояса в стиле POSIX подразумевает использование американских правил перехода на летнее время. При необходимости это можно поменять, заменив файл posixrules.
Примечание
Механизм использования файла posixrules переведён в IANA в разряд устаревших, так что в будущем он может быть удалён. Но в нём есть один дефект, который вряд ли будет устранён до момента его удаления. Вследствие этого дефекта к датам после 2038 г. невозможно применить правила перехода на летнее время.
В случае отсутствия файла posixrules выбирается правило M3.2.0,M11.1.0, соответствующее правилу перевода часов, действующему в США в 2020 г. (то есть переход на летнее время производится во второе воскресенье марта, а назад — в первое воскресенье ноября; часы переводятся в 2:00).
Например, запись 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 ввиду отсутствия подходящего файла posixrules.
Имейте в виду, что ошибиться в указании часового пояса в стиле POSIX очень легко, так как адекватность аббревиатуры никак не проверяется. Например, команда SET TIMEZONE TO FOOBAR0 выполнится без ошибки, и система в итоге будет использовать весьма своеобразную аббревиатуру для UTC.