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

PostgreSQL-как отобразить дату в разных часовых поясах?

мой сервер находится в Центральном времени. Я хотел бы отобразить временные метки, используя Восточное время.

например, я хотел бы сделать 2012-05-29 15:00:00 as 2012-05-29 16:00:00 EDT .

как я могу этого достичь?

to_char(‘2012-05-29 15:00:00’::timestamptz at time zone ‘EST5EDT’, ‘YYYY-MM-DD HH24:MI:SS TZ’) дает 2012-05-29 16:00:00 (нет зоны).

to_char(‘2012-05-29 15:00:00’::timestamp at time zone ‘EST5EDT’, ‘YYYY-MM-DD HH24:MI:SS TZ’) дает 2012-05-29 14:00:00 CDT (неверно).

это работает, но это так смешно сложно, должен быть более простой способ: replace(replace(to_char((‘2012-05-29 15:00:00’::timestamptz at time zone ‘EST5EDT’)::timestamptz, ‘YYYY-MM-DD HH24:MI:SS TZ’), ‘CST’, ‘EST’), ‘CDT’, ‘EDT’)

2 ответов

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

обратите внимание, что с set [local] timezone вместо аббревиатур необходимо использовать полные имена часовых поясов (например, CST не будет работать). Посмотрите в pg_timezone_names просмотр допустимых вариантов.

чтобы использовать этот метод в контексте, подобном вызову to_char (), I поверьте, эта функция выполняет эту работу:

на самом деле, PG знает все это — to_char (x, ‘TZ’) отличает CST от CDT правильно,и в часовом поясе EST5EDT уважает DST.

при работе с меткой времени Postgres знает:

• настройка GUC timezone .
• на тип данных.
• на стоимостью, который является тем же количеством секунд с «1970-1-1 0: 0 UTC» для timestamp и timestamptz . (Или, если быть точным: UT1.)
• подробнее о других часовых поясах в вашем файлы конфигурации даты / времени

при интерпретации входных данных Postgres использует информацию о предоставленном часовом поясе. При отрисовке значения метки времени Postgres использует настоящее timezone настройки, но часовой пояс смещение, аббревиатура или имя используются только для вычисления правильного стоимостью on вход. Они не спас. Это невозможно извлечь эту информацию позже. Подробнее в этом обзоры ответа:

ваш «правильный» пример почти правильно. TZ of to_char() возвращает «CDT»для меток времени, которые попадают в переходные периоды Центрального времени и» CST » еще. Восточное Время ( EST / EDT ) переключает летнее время на то же самое местные время — Цитирую Википедию:

время корректируется в 2: 00 по местному времени.

эти два часовых пояса рассинхронизация в течение двух часов в год. Конечно, это никогда не может повлиять на отметку времени в 15:00 или 16:00 , только 02:00 .

полностью правильное решение-очень похоже на то, что @Daniel уже опубликовал, немного упрощено:

эффекты локального набора длятся только до конца текущая транзакция.

Источник

Метка времени (timestamp) PostgreSQL To_char с часовым поясом

Методы форматирования PostgreSQL включают полезный набор инструментов для преобразования различных типов данных (дата / время, целые числа, числа с плавающей запятой, числовые) в форматированные строки и преобразования форматированных строк обратно в уникальные типы данных. Впредь иногда нам нужно также конвертировать часовые пояса. Время всегда записывается в формате UTC в метках времени PostgreSQL для формы данных часового пояса, но по умолчанию отображается в браузере, сеансе или по местному времени пользователя. Одна из его вспомогательных функций, на которую мы привыкли полагаться, — это метод TO_CHAR (), который, среди прочего, позволяет использовать метки времени и метки времени с часовым поясом и позволяет вам упорядочивать части метки времени, как вам нравится.

Метка времени, двойная точность, продолжительность, число или числовое значение могут быть преобразованы в строку с помощью метода PostgreSQL TO_CHAR (). Кажется, существует метод с одним аргументом, to_timestamp, который принимает аргумент с двойной точностью и преобразует эпоху Unix в метку времени с использованием часового пояса. В этом посте мы покажем вам, как что-то с этим сделать. Давайте сначала подробнее рассмотрим to_char ().

Синтаксис

Общий синтаксис функции to_char () следующий:

Метод TO_CHAR () в PostgreSQL требует двух утверждений:

• Выражение: метка времени, продолжительность, число, двойная точность или числовое значение, которое переводится в строку в соответствии с определенным форматом, могут использоваться как выражения.
• Формат: стиль, в котором будет отображаться строка вывода. Формат может отличаться в зависимости от типа выражения, например числа, даты.

В PostgreSQL доступны два типа временных меток:

• Отметка времени: без часового пояса.
• Timestamptz: с часовым поясом.

И вот в чем проблема: стандартная форма данных временных меток не учитывает часовые пояса. И это необходимость в SQL (как это могло произойти, кажется, за гранью). Наша основная цель — изучить метку времени to_Char () с часовым поясом. Чтобы начать работу с PostgreSQL с функцией to_char (), откройте оболочку командной строки PostgreSQL и введите значения параметров для обязательного сервера, базы данных, номера порта, имени пользователя и пароля. Оставьте эти соображения незаполненными, если вам нужно использовать параметры по умолчанию, как показано на изображении ниже.

To_char () для строкового числа

Чтобы понять концепцию функции to_Char (), использующей временную метку с часовым поясом, вы должны сначала попробовать пример строковых чисел. Итак, у нас есть число «1897», и мы будем преобразовывать его в формат «9999,99», используя запрос ниже. Из выходных данных ниже видно, что номер строки был преобразован в указанный формат.

Вот еще один пример обращения. На этот раз мы преобразовали число в другой формат, добавив в него запятую. Символ «G» будет использоваться для обозначения запятой.

To_char Timestamp с часовым поясом

Чтобы понять концепцию отметки времени с часовым поясом, давайте рассмотрим простой пример. Предположим, вы находитесь в «Пакистане», поэтому сейчас ваш часовой пояс должен быть «PKT».

Пример 1

Давайте попробуем получить текущую метку времени в запросе SELECT при преобразовании ее в формат даты и времени, как показано в запросе ниже. Термин «TZ» используется для возврата текущего часового пояса. На выходе отображается день, дата, время и часовой пояс.

>> SELECT to_char ( CURRENT_TIMESTAMP , ‘Day Mon dd, yyyy HH12:MI AM (TZ)’ ) ;

Давайте изменим наш часовой пояс на «Европа / Рим».

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

Пример 2

Когда вы указываете часовой пояс в запросе SELECT, в выходных данных не будет отображаться текущий часовой пояс, как показано ниже.

>> SELECT to_char ( CURRENT_TIMESTAMP AT TIME ZONE ‘Asia/Jerusalem’ , ‘yyyy HH12:MI AM ( TZ ) ‘);

Пример 3

Давайте создадим быструю таблицу с именем «время» с двумя полями. Один относится к типу TIMESTAMP, а другой — к типу TIMESTAMPTZ.

>> CREATE TABLE time ( without_timezone TIMESTAMP , with_timezone TIMESTAMPTZ ) ;

Теперь давайте проверим текущий часовой пояс, который мы использовали в нашей системе, используя команду SHOW в оболочке следующим образом:

Теперь вам нужно вставить текущие значения даты и времени текущего часового пояса, который вы использовали на своем устройстве, в таблицу «время», используя функцию «now ()», как показано ниже.

>> INSERT INTO time VALUES ( now ( ) , now ( ) ) ;

Теперь вы можете получить запись из таблицы time, используя запрос SELECT, как показано ниже. Столбец без_времени показывает текущую дату и время без часового пояса, а столбец with_timezone показывает местное время с часовым поясом полностью.

Давайте изменим часовой пояс на «US / EASTERN» из запроса ниже.

>> SET SESSION TIME ZONE ‘US / EASTERN’ ;

А теперь давайте еще раз проверим таблицу. Вы увидите, как значение столбца with_timezone было отображено в соответствии с часовым поясом «US / EASTERN», но значение «without_timezone» осталось таким же, как и раньше.

Пример 4

Приведем еще несколько примеров для метода to_char (). Предположим, что та же таблица «время» выше. Мы будем преобразовывать значение столбца without_timezone в строку, состоящую из часов, минут, секунд и часового пояса. Давайте попробуем запрос SELECT с использованием метода to_char () для преобразования значения столбца без_временной зоны. Мы упомянули «TZ» в нашем запросе, но он не покажет часовой пояс. Потому что значение столбца не состоит из часового пояса. Приведенная ниже команда дает результат:

>> SELECT to_char ( without_timezone , ‘HH12:MI:SS TZ’ ) FROM time ;

Теперь давайте попробуем тот же запрос в случае другого столбца with_timezone. Чтобы преобразовать его в строку часов, минут, секунд и часового пояса. На этот раз он также покажет часовой пояс со временем, используя запрос ниже.

>> SELECT to_char ( with_timezone , ‘HH12:MI:SS TZ’ ) FROM time ;

Заключение

Поскольку проблема с / без часового пояса влияет не только на разбиение таблицы на разделы. Я рекомендую вам по возможности использовать тип часового пояса. Практически во всех руководствах обсуждается, как выполнять очистку в PostgreSQL в зависимости от времени, используя местные часы. Правильное решение, чувствительное к часовому поясу, немного усложняет работу, но может уберечь вас от неприятностей в будущем.

Источник

Как мне навсегда изменить часовой пояс на 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.

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

Если задаётся аббревиатура для летнего времени, но правило перехода не задано, Postgres Pro пытается определить время перехода, обратившись к файлу 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.

Источник