Штамп времени PostgreSQL с часовым поясом применяет смещение при чтении - PullRequest
0 голосов
/ 01 февраля 2019

Прежде всего я знаю, что об этом много тем, и я мог бы использовать там решения, например написать функцию python, которая преобразует объект datetime в нужный мне часовой пояс, и добавить его в качестве фильтра в jinja2.

Но я хотел пропустить этот шаг.

Обычно PostgreSQL сохраняет объекты даты и времени в UTC.

Что я сделал: я изменил часовой пояс по умолчанию, который использует postgreSQL для сохранения объектов даты и времени: Europe/Berlin

ALTER DATABASE postgres SET timezone TO 'Europe/Berlin';

Это сработало, SHOW timezone; говорит мне, что это Europe/Berlin.

Но то, что делает Postgres, все равно сохраняет дату и время как UTC, но со смещением +1 для Европы / Берлина, что на самом деле непроблема.

Я предполагал, что при чтении объекта datetime Postgres применяет смещение и возвращает европейское / берлинское время, но это не так.Он по-прежнему возвращает время UTC, так какой смысл менять часовой пояс?

Мне все еще нужно написать этот фильтр и вручную преобразовать его.

Я думаю, что должен быть простой способ применить смещение на уровне БД, или я ошибаюсь?

РЕДАКТИРОВАТЬ

Некоторая информация, которая может помочь, модель:

class User(UserMixin, Base):
    __tablename__ = 'users'
    date_added = Column(DateTime(timezone=True), nullable=False)

Как это выглядит в БД:

enter image description here

А вот пример того, как я загружаю его в jinja2 / html:

{{ tenant.date_added.strftime('%d.%m.%Y um %H:%M Uhr') }}

1 Ответ

0 голосов
/ 01 февраля 2019

Во-первых, вы правы, чтобы справиться с этим полностью в базе данных.При работе с часовыми поясами либо используют timestamp with time zone по всему и позволяют базе данных обрабатывать преобразования и тому подобное, или используют timestamp without time zone по всему, сохраняют временные метки UTC и позволяют приложению иметь дело со временемзона обработки.Смешивать эти два обычно не очень хорошая идея.

PostgreSQL внутренне хранит timestamp with time zone как метку времени в UTC.После преобразования в строку, например, когда данные отправляются клиенту, данные преобразуются в часовой пояс сеанса , который настраивается параметром timezone.

Настройка timezone с помощью ALTER DATABASE изменит настройку для всех будущих сеансов , т. е. вам придется отключиться и повторно подключиться, чтобы новые настройки вступили в силу.

Однако каждый сеанс свободен (и рекомендуется) изменить timezone с помощью команды SET или функции set_config, и это определяет, в какой часовой пояс будут преобразованы временные метки.Используйте SHOW timezone для просмотра текущих настроек.

Если вы храните временную метку без явного часового пояса (например, 2019-02-01 12:00:00), она будет интерпретирована в вашем часовом поясе текущего сеанса.Таким образом, если это Europe/Berlin, отметка времени UTC, сохраненная внутри, будет 2019-02-01 11:00:00 UTC.Теперь, если вы SELECT значение, оно будет отображаться как 2019-02-01 12:00:00+01, потому что это ваше текущее смещение часового пояса.Если вы измените timezone, то же значение будет отображаться по-разному.

...