спасибо за дискуссию, подумаю на досуге, реально ли неиспользование timestamptz меня как-то кусает, либо нет.
по крайней мере нужно рассмотреть примеры, которые показываю в чем косяк такого подхода и применить их на себя.
а на счет зеркала, это вы перегнули конечно, ведь "у меня все работает, что я делаю не так?". вопрос риторический.

> меня как-то кусает, либо нет.

Может, и не "кусает" — если вся работа с датой/временем в этой базе в postgres тривиальна, например (ещё легче, если данные приходят из какой-то одно time zone, где нет и никогда не было DST, ну и так далее).

> это вы перегнули конечно

Нет, не "конечно". Вы систематически проверяете корректность "своих" данных и результатов запросов?
А то я неоднократно сталкивался с ситуациями "у меня все работает, что я делаю не так?"... а потом аудиторы проверяют "документы vs база"... и где-то тут не хватает 10000$ (это один из реальных случаев, кстати).

>Может, и не "кусает" — если вся работа с датой/временем в этой базе в postgres тривиальна, например (ещё легче, если данные приходят из какой-то одно time zone, где нет и никогда не было DST, ну и так далее).

да просто договорились, что все события в БД записываются по Гринвичу, часовых поясов нет, делать запросы в БД с преобразование времени к тому или иному часовому поясу не нужно.
приложение берет время из БД, проверяет часовой пояс клиента на устройстве, и уже само добавляет время относительно Гринвича.
примерно так.

Ну так тут ничего нетривиального, на первый взгляд, и нет.
Даже обработки в самом postgres никакой нет, или пропустил?

почему Гринвич-то? у него же DST, он плавает. UTC надо боать

имею в виду UTC+00

Я так понял, что имелось в виду... да, вот это. ;)

под обработкой в самом postgres имеем ввиду именно преобразование времени?

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

Любую обработку, да.
Сравнение с текущим, группировку (по часам или по датам, например), вычисление интервалов и так далее.

задам вопрос разрабам, спасибо за наводку.
если вся обработка выполняется на стороне приложения, то проблем с  timestamp нет?

почитал, в общем text предпочтительнее, понятно.

Нет, но именно потому, что оно используется как bytea (blob), по факту.
Т.е. положил / взял и всё, его можно было бы хранить как угодно (т.е. тип "безразличен" СУБД).

а к bytea можно применить всякие сортировки, order by, now - 1 и прочие запросы, чтобы хотя как-то +- удобно работать все же как со временем.

Нет, конечно.
Но если Вы такое применяете к этим данным (Вы ничего об этом ранее не писали!), то проблемы уже могут быть.

просто с timestamp я могу сделать запрос - "покажи мне строки, добавленные за последний час от now"

Не можете. Тип now() — timestamptz. И "поздоровайтесь" со всеми проблемами преобразования.
Т.е. тут уже нужно думать и аккуратно писать.

> (Вы ничего об этом ранее не писали!)
да, сейчас я спрашиваю просто про пользовательской опыт в клиенте SQL, не про приложение.

хорошо, ознакомлюсь с проблемами преобразования, как именно это "кусает"
потому что просто взять и заменить timestamp на бинарный формат, по которому даже order by не сделать, это мне не подходит.

Т.е. работать хотите, а правильно хранить — нет? ;)

Что ж, дело Ваше. Но я бы сказал, что если данные "сложные" — на этом можно запросто "споткнуться", даже если хорошо в этом разбираться  (у работы с локальными датами и временами более чем хватает собственных проблем, добавлять к этому ещё и "пляски" с преобразованиями из/в неправильный тип — удовольствие ниже среднего, т.е. чистая потеря времени и надёжности).