коллега, Оракл в отношении дат известные колхозники! да, я помню эту боль…

Нет, подождите.
Для работы с "абсолютными" моментами времени есть только один правильный тип — timestamptz.

А что касается работы с локальным "временем", то для этого есть timestamp и так далее — тут уже всё зависит от ситуации.
В частности, для хранения запланированных событий обычно рекомендуется timestamp + название time zone (что, строго говоря, неверно, но почти всегда "сойдёт"). Ну и так далее.

Хмм... зачем мне гуглить про Oracle-проблемы? ;)

я это к тому, что PG у нас живет не в вакууме и иногда приходится использовать не лучшие практики для большей совместимости

понятно, что это не проблемы PG, я ток хотел написать, что ссылка выше не является сводом законом и нужно подключать критическое мышление и там

О-хо-хо. При таком хранении (в других типах и в UTC) Вы лишаетесь возможности надёжно корректно работать с ними в PostgreSQL (т.к. все функции "нацелены" на timestamptz, то только и ждут, как "укусить" ;) ). И примеры подобного тут неоднократно показывали, кстати.
Т.е. лучше б его хранили в text (или bytea), во избежание поползновений что-то с ним сделать в postgres, честное слово. ;)

Так вот, в чём конкретно была проблема вывода timestamptz в Oracle или ещё куда (из него можно сформировать правильное время в произвольном формате, если нужно — потому что, в отличие от всяких "костылей", он хранит настоящее время)?

кто ж спорит…

Лучше "отключить" свою самонадеянность и подумать о том, что "ссылка" написана людьми с огромным опытом эксплуатации этой СУБД, и она в основном про antipattern-ы.
Ну а Вы помните определение antipattern, да? ;)

конкретно проблема была в том, что kafka connect sink jdbc не может записать время с формате timestamptz в оракл, в колонку с типом данных date.
Можно записать в колонку с типом данных аналогичным text, например, но тогда с датой через функции работы с датой не поработать.

потому что date не предназначен для этого, совсем

при этом timestamp можно записать в date.
я выбрал его.
какие ваши предложения?

Про первое уже ответили. А про второе я тоже уже написал: "лучше б его хранили в text (или bytea), во избежание поползновений что-то с ним сделать в postgres, честное слово.". Т.е. так можно хранить, если корректность результатов запросов при работе с ним в PostgreSQL для Вас не имеет значения.

In Oracle9i release 1 (9.0) and up there is a datatype TIMESTAMP WITH TIMEZONE
у вас там 8 версия?

нет конечно, минимум 12.
но видимо тот формат, что PG дает из коробки не позволяет записать в оракл через sink коннектор

А преобразовывать при "записи" (что бы это ни значило) оно тоже не умеет?
Т.е. там тупо встроено что-то вроде "SELECT * FROM a_table;", что ли?

можно заценить доку тут, там немного:
https://docs.confluent.io/5.5.3/connect/kafka-connect-jdbc/sink-connector/index.html

в кафка-коннекте есть такая штука как SMT, но я уже не стал вкуривать как это прикрутить на sink

можно было б с этой темой поупражняться, но на момент выхода этого демо, передо мной задачи синка уже не стояла:
https://rmoff.net/2020/12/17/twelve-days-of-smt-day-8-timestampconverter/

Ну и вон же там возможность указывать какие-то типы (и для timestamp для PostgreSQL соответствие по умолчанию либо неверное, либо в самой kafka тип кривой)?

Мне кажется (если всё действительно можно было сделать правильно), или это просто был вариант "хренак-хренак и продакшн!"? В таком случае зачем на "зеркала"-то пенять? ;)