Точнее даже не правил, а советов.

даже timestamptz не даёт полной гарантии точного результата при работе с датами, но он гораздо лучше чем просто timestamp. именно по этой причине там дана такая рекоммендация и она очень обоснована. для заливки в другие системы можно:
- делать пре-процессинг ( в лоб, через COPY (SELECT id, created_at::timestamp, … ) TO … )
- для кафки конкретно можно debezium прикрутить
- или wal2json

на хабре (кажется) была отличная статья, показывающая, что timestamptz недостаточен

далее почитал про varchar(n), согласен, что это больше советы, чем правила.
если так воспринимать, то ссылка полезная.

>- для кафки конкретно можно debezium прикрутить
вот дибизиум и прикрутил, в кафку timestamptz нормально льет, не спорю.
проблемы возникают, когда начинаешь делать sink этих значений в другие БД, не постгрес, где нет такого типа данных как timestamptz
Можно применить всякие SMT на сообщения, но все это показалось мне слишком сложным, чем просто договориться с разрабами хранить время по гринвичу и добавлять часовые пояса на клиентах.

Значит, эта ваша kafka, внезапно, не умеет правильно работать с датой/временем.

Я именно об этом, да.

Почему это "не даёт"? Для "гражданских" даты/времени — вполне, при правильном использовании.

А ссылки на эту статью у Вас не завалялось (почти все эти статьи пишутся от непонимания сути работы с timestamp-ами, вот что печально)?

Просто varchar(n) тупо хуже (трудно назвать хоть какие-то преимущества), чем text+CHECK, вот и всё.
Т.е. совет состоит в использовании инструмента получше вместо того, который похуже, вот и всё.

А в чём состояла трудность использовать в клиентских сессиях postgres timezone UTC?

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

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

вроде эта: https://habr.com/ru/post/278527/

When you want to, really. If what you want is a text field that will throw an error if you insert too long a string into it, and you don't want to use an explicit check constraint then varchar(n) is a perfectly good type. Just don't use it automatically without thinking about it.

чем varchar(n) тупо хуже text ? по ссылке сказано, что отличный тип, когда знаете что делаете и не хотите навешивать явные ограничения.
на современных PG он требует больше памяти или диска, нежели text?

Я это где-то расписывал подробно, минуту...

в момент, когда нужно положить timestamptz в оракл, да не просто положить как текст, но чтобы и функции работы с датами работали

в целом, вполне дельный вывод для себя сделал, что при планировании событий на будущее (отдалённое) всё может “поплыть”, если сдвиг зоны поменяют пока мы ждём

Ну так это проблемы именно Oracle (если они вообще есть, что-то я сомневаюсь).

>если они вообще есть, что-то я сомневаюсь
можете загуглить как положить постгрес timestamptz в оракл, но так, чтобы функции работы с датой работали

пасиб, заценим, но tl;dr нет, нужно вдумчиво почитать