она разве не сама должна увеличиваться по значению, мб можно как то обновить?

все, починил

согласен, если требуется порядок вылета, нужна сортировка по utc. Честно говоря, придумать кейса для сортировки по локальному времени я не могу, так что мой экспериментальный скрипт не корректен, ибо проверяет не то, что нужно. Тем не менее, изменить сортировку на использование utc тривиально.
Тем временем погуглил real-world DST observing в аэропортах.
Данных нашёл не очень много.
Во-первых, есть соответствующий вопрос на стэке. В нём отвечают, что, на основании личного опыта, на неоднозначный час не планируется вылетов и прилётов пассажирских рейсов. Не пассажирские оперируют только UTC.
Во-вторых, жиденькие (из-за количества данных) подтверждения этому есть тут. Например, аэропорт SEA (рейсы American Airlines) на Nov 5 2017. Самый ранний вылет - в 06:00 (полагаю, местного времени), в то время как повторяющийся час - 01:00:00-02:00:00

SELECT date_trunc('day', now());

"весело", да.
Правда, кажется, задействована бубенная магия. date_trunc показывает время 00:00

SET timezone=DEFAULT;
SELECT now();
SET timezone='UTC';
SELECT now();

оба раза показывает одно и то же (локальное) время с поправкой на секунды между вызовами

> Тем не менее, изменить сортировку на использование utc тривиально.

Это да. Но суть, вообще, была не в этом, в в том, что достаточно немного пропустить в подобных случаях — и вот PostgreSQL уже преобразовал значение в  timestamptz (по зоне сессии, конечно), или использовал "не ту" функцию и т.п.

> в то время как повторяющийся час - 01:00:00-02:00:00

Если бы. :( Это так только в более-менее "вменяемых" местах.

к сожалению, статистику по родным, невменяемым, не нашёл

Смотря какие "родные".
А так — вообще в мире есть совершенно безумные связанные с этим правила, если что. ;)

верю =)
Проглядывал исходники tzdb, запомнился забавный кейс аргумента против моделирования оффсетов целыми часами/минутами - 1900-01-01 00:00:00 Europe/Paris.

Спасибо за дискуссию, подчерпнул нового для себя.

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

Хорошего Вам времени!

Да раньше-то там вообще был кошмар, это понятно (когда общего мирового времени не было). :)
Но и сейчас всякого неприятного хватает...
Вот, к примеру: https://en.wikipedia.org/wiki/Daylight_saving_time_in_Morocco

during the month of Ramadan during which clocks reverted to UTC+00:00 (standard time).

Что "радует" — даты перевода часов каждый год разные (Ramadan lasts twenty-nine to thirty days, from one sighting of the crescent moon to the next), и никак не "завязаны" на дни недели, как у нас. К счастью, это в конце концов достало даже их. ;)
Но, тем не менее, время от времени что-нибудь "весёлое" всё равно кто-то вводит.

привет всем! Кто может подсказать, как в клиенте PostgreSQL перейти на последнюю строчку в таблицу сразу не писав SELECT Order By DESC

в каком из клиентов?)

В реляционных базах данных нет понятия очерёдности данных.

что вообще значит "перейти на последнюю строчку"?

Может выбрать данные из последней строки?

а что такое последняя строка?

А что такое ЧТО?

Как первая, только с конца.

не факт.

Пример?

Это тыкнуть мышкой по названию поля, и оно в обратном порядке отсортирует)