Конечно, удивлюсь, потому что это неправда.
https://www.postgresql.org/search/?u=%2Fdocs%2F13%2F&q=postgresqltutorial

Это не документация PostgreSQL, а его сайт, Вы путаете.
Документация — это то, что находится вот тут: https://www.postgresql.org/docs/ (в разных форматах и про разные версии).

Там 3000 страниц. Это точно единственный способ изучить SQL?)

По этому поводу — верить можно только документации.
К сожалению, в раздел ссылок на сайте, грубо говоря, вносят всякого, кто попросил, поэтому там есть и совершенная дрянь (особенно в разделе "книги"), которая может дать только отрицательные знания PostgreSQL. :(

Есть и хорошие книги, говорят... но я лично не читал ничего выше среднего (и это в самом лучшем случае!).
Но тут советовали что-то... поищите.
И, кстати, в самой документации PostgreSQL тоже есть tutorial (он тоже не очень, но там, хотя бы, нет фактических ошибок, кажется). ;)

Ну ладно, всякий случай уточню: русский перевод хотя-бы корректный?

Не знаю, почти не читал.

В любом случае, спасибо

Нужно добавить сортировку по description. Если сортировка не указана, то база в произвольном порядке отдаст данные

понял, спасибо)

Я считаю что это фича удобная, из коробки база будет нормально работать c timestamptz для клинетов в разных time zone. Конечно можно все сделать руками и есть work-arounds это не блок проблема, но фича реализована в других базах, почему многие против мне непонятно.

Собственно мой первый вопрос был почему это не реализаванно, возможно что данная реализция таит в себе скрытые проблемы.

Пока ответа не услышал.

А можно пример использования фичи?

У меня проект есть по Москве, но клиенты до Хабаровска и Магадана

> из коробки база будет нормально работать c timestamptz для клинетов в разных time zone.

Не будет. Потому что магии не существует.

> Конечно можно все сделать руками и есть work-arounds

Так, сколько можно уже объяснять... это не workarounds!
Не нужно тащить дефекты из других СУБД в PostgreSQL, понимаете?

> но фича реализована в других базах, почему многие против мне непонятно.

А Вы поняли, как это всё работает, и почему это именно так?
Мне кажется, что нет.

> Пока ответа не услышал.

Вы его услышали уже неоднократно, IMNSHO.

Клиенты из Москвы и Хабаровска например, сохраняют в базе время в локальном формате, сервер переводит в UTC корректно при условии что timezone установленна правильно для каждого клиента.
Подключается клиент из например NY и видит время событий Москвы и Хабаровска в своем локальном времени.

Если я правильно понимаю, это работает только если у клиентов установлена правильно timezone и используеться тип данных timestamptz.

Причем какая таймзона установлена у сервера не важно.

Подскажите как вы решали эту проблему ?

Это очень опасный подход, кмк. Особенно, если клиентов больше одного. Ибо назавтра кто-то из клиентов где-то внутри своей бизнес-логики сделает приведение к какой-нибудь левой tz и все сломается

Я, как мне кажется, внимательно это прочитал.
И тут, с виду, всё работает правильно. В чём конкретно Вы видите проблему?

В базе должны лежать только значения в utc. Все остальное - задача клиента, ему видней

Какой именно подход? Хранение в timestamptz и преобразования в нужную tz — это совершенно правильно.