Спецификации часового пояса POSIX
Эта страница переведена при помощи нейросети GigaChat.
PostgreSQL может принимать спецификации временных зон, которые написаны в соответствии с правилами стандарта POSIX для переменной окружения TZ
. Спецификации часового пояса POSIX недостаточны для обработки сложности реальной истории временных зон, но иногда есть причины их использовать.
Спецификация временной зоны POSIX имеет форму:
STD offset [ DST [ dstoffset ] [ , rule ] ]
Для удобства чтения показываются пробелы между полями, но на практике пробелы не должны использоваться. Описание полей:
STD
– аббревиатура зоны, которую следует использовать для стандартного времени.offset
– смещение стандартной временной зоны от UTC.DST
– аббревиатура зоны, которую следует использовать для летнего времени. Если это поле и последующие поля опущены, зона использует фиксированное смещение UTC без правила перехода на летнее время.dstoffset
– смещение летнего времени от UTC. Это поле обычно опускается, так как оно по умолчанию на один час меньше стандартного времениoffset
, что обычно является правильным решением.rule
– определяет правило для определения времени действия летнего времени, как описано ниже.
В этом синтаксисе аббревиатура часового пояса может быть строкой букв, такой как EST
, или произвольной строкой, окруженной угловыми скобками, например <UTC-05>
. Обратите внимание, что аббревиатуры, приведенные здесь, используются только для вывода, и только в некоторых выходных форматах. Аббревиатуры распознаваемые во входных данных временной метки, определяются, как объясняется в разделе «Файлы конфигурации даты/времени».
Поля смещения указывают разницу во времени в часах и, при необходимости, минутах и секундах от UTC. Они имеют формат hh[:mm[:ss]]
с необязательным ведущим знаком (+
или -
). Положительный знак используется для зон западнее Гринвича. Обратите внимание, что это противоположно соглашению о знаках ISO-8601, используемому в других местах в PostgreSQL. hh
может содержать одну или две цифры; mm
и ss
(если используются) должны иметь две.
Переход на летнее время rule
имеет формат:
dstdate [ / dsttime ] , stddate [ / stdtime ]
Как и раньше, пробелы не следует включать на практике. Поля dstdate
и dsttime
определяют начало летнего времени, а поля stddate
и stdtime
определяют начало стандартного времени. В некоторых случаях, особенно в зонах к югу от экватора, первое может быть позже в году, чем второе. Поля даты имеют один из следующих форматов:
n
– простое целое число обозначает день года, считая от нуля до 364 или до 365 в високосные годы.Jn
– в этой формеn
считает от 1 до 365, и 29 февраля не учитывается даже при его наличии. Таким образом, переход, происходящий 29 февраля, не может быть указан таким образом. Однако дни после февраля имеют те же номера независимо от того, високосный год или нет, поэтому эта форма обычно более полезна, чем простая целочисленная форма для переходов в фиксированные даты.Mm.n.d
– эта форма указывает на переход, который всегда происходит в течение одного и того же месяца и в один и тот же день недели.m
определяет месяц с 1 по 12.n
задаетn
-й случай дня недели, определенногоd
.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 часа ночи по центральноевропейскому времени и заканчивается в последнее воскресенье октября в 3 часа ночи по центральноевропейскому летнему времени.
Четыре названия часовых поясов EST5EDT
, CST6CDT
, MST7MDT
и PST8PDT
выглядят так, будто они являются спецификациями зоны POSIX. Однако на самом деле они обрабатываются как именованные временные зоны, потому что (по историческим причинам) существуют файлы с такими именами в базе данных временных зон IANA. Практическое следствие этого состоит в том, что эти имена зон будут производить действительные исторические переходы на летнее время в США, даже когда простая спецификация POSIX не будет работать.
Следует быть осторожным, так как легко допустить опечатку при указании спецификации временной зоны в стиле POSIX, поскольку нет проверки разумности сокращения(ий) зоны. Например, SET TIMEZONE TO FOOBAR0
будет работать, фактически оставляя систему использовать довольно странное сокращение для UTC.