её в изначальное сообщение. Ок, в следующий раз буду прикладывать и то, и то, одним сообщением.
Спасибо за пояснение, помогло оформить мысль точнее и найти ответ.
Возвращаясь к оригинальному вопросу, почему timestamptz at time zone возвращает timestamp, а не timestamptz с зоной отображения? Простой ответ, кажется, в том, что тогда пришлось бы где-то хранить эту самую "зону отображения". Соответственно, мой вопрос транслируется в "почему разработчики ПГ решили не хранить таймзону в рамках timestamptz?". Что приводит к этому письму.
То, что хотел бы от ПГ я - это хранение timestamp utc + timezone. Что пытались сделать, но не захотели включать строковое значение в хранение и не смогли (то же письмо) включать не строковое.
Почему я всё это начал. Была база без таймзон, приложению понадобились таймзоны, рассматривал варианты, включая нативные таймзоны ПГ. Из-за того, что timestamptz зону не хранит, а приложению будет говорить, что это время в зоне, установленной на соединении, чтобы избежать непонимания от разработки и необходимости это объяснять, буду, видимо, хранить пару из utc TIMESTAMP и iana_timezone_id CHARACTER VARYING, с ручной конвертацией на приложении и AT TIME ZONE 'utc' AT TIME ZONE iana_timezone_id в скриптах, благо, последних используется значительно меньше.
В ответе на вопрос надеялся найти указание на тип/расширение/..., которое реализует честное время с таймзоной или знание, что его нет. Немного дальнейшего гуглинга привело на https://github.com/mweber26/timestampandtz, но писать поддержку дополнительного формата данных в бинарный протокол для провайдера в мои временные рамки не входит. Может, как-нибудь сделаю это в свободное время
> Возвращаясь к оригинальному вопросу, почему timestamptz at time zone возвращает timestamp <skip> Потому, что реализация была когда-то выполнена в стиле "и нашим, и вашим". Т.е. чтобы и работало, и было на первый взгляд похоже на ISO SQL (который менее чем бесполезен в этом отношении) — а зря, IMHO (надо было нарушать так нарушать — чтобы не было такой путаницы, как сейчас). Поэтому features стандарта, вроде AT TIME ZONE и т.п., использовали, только смысл у них другой. ;) > мой вопрос транслируется в "почему разработчики ПГ решили не хранить таймзону в рамках timestamptz? Потому что для хранения моментов времени — это тупо и бесполезно. :) > То, что хотел бы от ПГ я - это хранение timestamp utc + timezone. А зачем? Вам, скорее всего, зря кажется, что Вам это нужно. > не захотели включать строковое значение в хранение и не смогли Но если Вам действительно нужно, Вы-то можете добавить текстовое поле для time zone. > чтобы избежать непонимания от разработки и необходимости это объяснять Если "разработка" не понимает, как правильно работать с timestamp-ами, проблемы у вас вскоре будут куда большие (если данные хоть как-то важны). :(
Обсуждают сегодня