Comments 7
Иногда именами собственными — Europe/Moscow, America/Chicago, Africa/Cairo и т.д. Postgres «понимает» такую форму, умеет определять зимнее и летнее время, с этим всё хорошо.
Цитирую документацию:
TZ upper case time-zone abbreviation (only supported in to_char)
tz lower case time-zone abbreviation (only supported in to_char)
TZH time-zone hours
TZM time-zone minutes
OF time-zone offset from UTC (only supported in to_char)
Это форматы для преобразования в строку. Говорите, «Postgres «понимает» такую форму»? И все хорошо? А где тогда преобразование зоны в этот формат? Я хочу получить строку, где написано «Europe/Moscow», как это сделать? Похоже что никак. Между тем, Oracle в той же функции to_char позволяет задать формат TZR, и получить искомое.
Иногда удобнее использовать сокращения — MSK, PST, и т.д.
Также можно использовать цифру — смещение относительно UTC, но тогда будут проблемы с зимним и летним временем; впрочем, для них тоже есть достаточно неудобоваримый синтаксис, гурманы могут попробовать.
Что для вас значит «удобнее», если это три разные вещи? С тремя разными поведениями. Europe/Moscow, MSK/MSD и UTC+03 — не взаимозаменяемы.
Да ну божечки же... В постгресе без костылей в виде пустой партиционированной таблицы нельзя узнать, в какую партицию упадёт строка, если партиционирование хеш по модулю, потому что Эррера всё никак не сообразит, как заставить партиционированные индексы следовать в тейблспейс за своей партицией таблицы.
А Лейн зарядил пулеметную ленту и засел в дзот обороняться от багрепортов. Таких, как IF NOT EXISTS на самом деле не всегда предотвращает исключение, хотя документация уверяет в обратном.
В общем, им не до консистентности.
Я не совсем понимаю зачем хранить в БД не UTC время?
В постгресе хранится именно UTC, если поле timestamptz, приведение происходит безопционально и автоматически.
Если время хранится числом (unix epoch, JS getTimeMillis() и тп), всё зависит только от прозорливости разработчиков, сделали ли они работу над приведением в коде приложения, или нет, учли ли они то, что рантайм может иметь другую, отличную от изначальной установленную таймзону, установлены ли локальные часы системы в UTC, или, как в винде, в локальное время в заданном часовом поясе. В общем, хранить время в постгресе не в timestamptz -- себе дороже.
Всегда использую типы без TZ, не отдаю преобразование часовых поясов на откуп сессии БД. Преобразую уже на беке или даже на фронте, если нужно только отобразить.
Потому что есть три разных времени:
Часовой пояс сервера (может быть вообще любым в зависимости от фантазии сисадмина и физической локации сервера).
Часовой пояс бизнес-логики. Ну то самое "посчитать количество рабочих дней". Очень легко при развитии системы оказывается, что их на самом деле несколько. Например, у фирмы появляется несколько филиалов в разных часовых поясах или в систему добавляют несколько независимых фирм в разных часовых поясах. И надо выбирать часовой пояс в зависимости от разных условий.
Часовой пояс пользователя. Нередко известен только фронту. Иногда нужно учитывать, иногда не нужно.
Короче, проще всего на часовой пояс сервера не полагаться, а принять, что все даты в UTC, а потом уже их переводить явно в нужный часовой пояс из ТЗ. Ну слишком уж легко отстрелить себе ногу. Ты глядишь на запрос и не знаешь, что он вернёт, не зная настроек сервера.
До тех пор, пока автономные транзакции приходится делать через dblink, timestamptz лучше вообще не пользоваться.
Темпоральные типы в PostgreSQL и их использование