Postgresql как настроить часовой пояс

Указание часового пояса в стиле POSIX выглядит так:

(Для наглядности между полями добавлены пробелы, но в реальном указании их не должно быть.) В нём содержатся следующие поля:

STD — аббревиатура, используемая для стандартного часового пояса.

смещение — стандартное смещение пояса от UTC.

DST — аббревиатура часового пояса при переходе на летнее время. Если это поле и следующие за ним опущены, для часового пояса будет использоваться фиксированное смещение от UTC без учёта перехода на летнее время.

смещение_летнего_времени — смещение часового пояса от UTC при переходе на летнее время. Это поле обычно опускается, так как по умолчанию это смещение равно стандартному смещению минус один час, что практически всегда имеет место на практике.

правило — определяет, как должен учитываться переход на летнее время, в соответствии с представленным ниже описанием.

В этой записи аббревиатура часового пояса может задаваться набором букв, например EST , или произвольной строкой, заключённой в угловые скобки, например . Заметьте, что показанные здесь аббревиатуры используются только при выводе и только в некоторых выходных форматах. Распознаваемые во входных значениях даты/времени аббревиатуры часовых поясов описаны в Разделе B.4.

В полях смещений задаётся сдвиг от UTC в часах и, возможно, минутах и секундах. Они имеют формат чч [ : мм [ : сс ] ] и могут содержать спереди знак ( + или — ). Положительный знак имеют часовые пояса к западу от Гринвича. (Заметьте, что это противоположно соглашению ISO-8601, используемому в других областях PostgreSQL .) Компонент чч может содержать одну или две цифры, а мм и сс (если они задаются) должны состоять ровно из двух цифр.

Поле, задающее правило перехода на летнее время, имеет следующий формат:

(Как и ранее, реальное указание не должно содержать пробелы.) Поля дата_перехода и время_перехода определяют момент перехода на летнее время, а поля дата_возврата и время_возврата определяют дату возврата к поясному времени. (В некоторых регионах, в частности, в Южном полушарии, вторая дата в календаре может предшествовать первой.) Даты могут задаваться в одном из следующих форматов:

Простое целое, обозначающее день года, с нумерацией от нуля до 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 .

Если задаётся аббревиатура для летнего времени, но правило перехода не задано, 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.

Источник

Postgresql как настроить часовой пояс

Указание часового пояса в стиле POSIX выглядит так:

STD — аббревиатура, используемая для стандартного часового пояса.

смещение — стандартное смещение пояса от UTC.

Поле, задающее правило перехода на летнее время, имеет следующий формат:

Простое целое, обозначающее день года, с нумерацией от нуля до 364, или 365 в високосном году. J n

Примечание

Если задаётся аббревиатура для летнего времени, но правило перехода не задано, в качестве правила по умолчанию используется M3.2.0,M11.1.0 , что соответствует существующему в США в 2020 г. порядку. То есть часы переводятся на летнее время во второе воскресенье марта, а на зимнее — в первое воскресенье ноября, в два часа по действующему времени. Заметьте, что это правило даёт правильные даты для США только с 2007 г.

Источник

часовой пояс postgres по умолчанию

Я установил PostgreSQL 9, и время, которое он показывает, на 1 час отстает от времени сервера.

под управлением Select NOW() показывает: 2011-07-12 11:51:50.453842+00

дата сервера показывает: Вт 12 июля 12: 51: 40 BST 2011

это на 1 час позади, но часовой пояс, показанный в phppgadmin: часовой пояс Etc / GMT0

Я попытался войти в postgresql.conf и установка часового пояса = GMT затем запуск перезапуска, но без изменений.

любые идеи, которые я думал, что это будет просто использовал часовой пояс сервера, но, очевидно, нет?!

решение!: Я установил GMT раньше, и это было на час позже..после поиска вокруг, оказывается, мне нужно установить его в Европу/Лондон. При этом учитывается +1 час по британскому летнему времени, GMT нет!

7 ответов

часовой пояс является параметром сеанса. Так, вы можете изменить часовой пояс для текущего сеанса.

док объясняет разницу:

установить часовой пояс расширяет синтаксис, определенный в SQL норматив. Стандарт допускает только числовые смещения часовых поясов, а PostgreSQL — более гибкие спецификации часовых поясов. Все остальные функции набора являются расширениями PostgreSQL.

чтобы завершить изменение часового пояса в Postgres 9.1, вы должны:

1.- поиск в папке » часовые пояса «в /usr/share/postgresql/9.1/ для файла appropiate, в моем случае будет» Америка.txt», в нем найдите ближайшее место к вашей зоне и скопируйте первые буквы в левой колонке.

например: если вы находитесь в «Нью-Йорке» или «Панаме», это будет «EST»:

2.- раскомментировать строку «часовой пояс» в ваш postgresql.conf файл и поместите часовой пояс, как показано:

3.- Перезапустить Postgres

Источник

Как мне навсегда изменить часовой пояс на UTC в postgres?

Я установил часовой пояс в postgresql.conf следующим образом: —

Но когда я вижу часовой пояс на сервере postgres, по умолчанию используется «Азия / Калькутта». Я установил postgres, используя пакет brew в MacOs.

2 ответа

Есть много способов установить переменные конфигурации. Но большая часть этих настроек может быть отменена клиентом внутри своей транзакции. (Некоторые настройки требуют перезапуска сервера или имеют другие ограничения, но не timezone .)

Чтобы быть абсолютно уверенным, что некоторые операции происходят с timezone = ‘UTC’ , вы можете инкапсулировать это в серверной функции с ее собственными настройками, переопределив любые пользовательские настройки. Найдите пример кода в этом связанном ответе:

Но хотя это соответствует формулировке вашего вопроса, я не думаю, что это то, что вы ищете. Возможно, вам просто нужно перезагрузить после изменения postgresql.conf , чтобы установить значение по умолчанию для новых сеансов.

Настройка timezone в postgresql.conf просто устанавливает значение по умолчанию для клиентов без этой настройки. Если вы видите другое значение, значит, клиент устанавливает для него некоторое локальное значение.

Или, как вариант, вы не перезагружали сервер:

Чтобы проверить настройку и то, что необходимо для ее включения, вы можете:

pending_restart false означает, что вам не нужно перезапускать postgres, но вам все равно нужно перезагрузить конфигурацию после изменения. Также, как вы видите, этот параметр влияет только на клиента. И, очевидно, клиент может легко переопределить это по умолчанию.

Чтобы установить часовой пояс на стороне клиента, просто запустите set timezone to ‘UTC’ .

Чтобы установить это для какого-то пользователя постоянно, используйте alter user uname set timezone и то же самое для установки по умолчанию для db.

Источник