pgsql – PostgreSQL

11 Mar 2025 09:50

В столбце created_on время в utc

pgsql – PostgreSQL

11 Mar 2025 09:48

Потому что 05:08GMT+05 это 00:08GMT, и это тоже самое что 03:08GMT+03. Формально, не то чтоб поэтому, но так работают часовые пояса, да (по определению формы этой записи).

Но, давайте начнем с малого: в столбце created_on указано локальное время, или же время в UTC/GMT (без всякого смещения, т.е., приведено специальным образом к этому формату)? Это кардинально меняет дальнейшие шаги. Изначально я его интерпретирую как первый случай, но может зря...

pgsql – PostgreSQL

11 Mar 2025 09:38

Почему ж вы так решили то? Всё правильно он показывает (если у вас в столбце created_on не время в UTC/GMT, а локальное, конечно).

Напр., 05:08GMT+05 это как раз 03:08GMT+03, как в вашей выделенной синим строке.

pgsql – PostgreSQL

11 Mar 2025 09:36

(c.created_on || replace (tz.offset, 'GMT',''))::timestamptz as created_on2 — не работает,
c.created_on::timestamp AT TIME ZONE 'GMT' AT TIME zone replace (tz.offset, '+','-') as created_on3 - работает

pgsql – PostgreSQL

11 Mar 2025 09:21

а как такое можно поправить, в offset заменить + на - ? 😳

pgsql – PostgreSQL

11 Mar 2025 09:18

c.created_on::timestamp AT TIME ZONE 'GMT' AT TIME zone tz.offset — почему то переводит наоборот где прибавить - отнимает

pgsql – PostgreSQL

11 Mar 2025 09:17

Да, это верно, выше привел ещё некоторые соображения в upd :)

pgsql – PostgreSQL

11 Mar 2025 09:14

Покажите ожидаемый и реальные результаты. Этот вариант должен "в другую сторону" время поменять на указанное смещение.

pgsql – PostgreSQL

11 Mar 2025 09:11

Этот вариант тоже не корректно работает((

pgsql – PostgreSQL

11 Mar 2025 09:09

Сейчас сам потестировал: PostgreSQL почему-то если видит GMT/UTC (или некоторые другие последовательности из букв, в т.ч. случайные) во входящей строке, то почему-то не "в ту сторону" время переводит, как коллега выше и говорит. Интересно, раньше как-то не обращал внимания.

pgsql – PostgreSQL

09 Mar 2025 17:00

Это можно сделать через гарантийное письмо от организации.

pgsql – PostgreSQL

08 Mar 2025 19:33

Ну, PostgreSQL то в этом контексте оперирует байтами, жестко ограничивая их кол-во как 63 байта для идентификаторов (к слову, в этом смысле русский алфавит в той же utf8 будет не в самом выгодном положении с его 2 байтами на символ).

pgsql – PostgreSQL

08 Mar 2025 19:00

Ох если бы это было шуткой.... У меня в таблице есть поля на русском языке....

pgsql – PostgreSQL

08 Mar 2025 18:26

То есть, дамоклов меч не грозит, если ответственность меньше отдыха? А сколько туплов в отношении «жизнь», хотя бы 9, как у кошки?

pgsql – PostgreSQL

08 Mar 2025 15:14

Продукт с сапортом) иное ну такое, как репа выше

pgsql – PostgreSQL

11 Mar 2025 09:49

потому

pgsql – PostgreSQL

11 Mar 2025 09:43

что-то я не понимаю, почему 05:08GMT+05 это не 10ч?

pgsql – PostgreSQL

11 Mar 2025 09:37

да, в вашем случае работает.
есть одна проблема: если у вас в tz.offset записано, к примеру, GMT-08:00 (или любой другой оффсет с GMT-), то это не сработает.

pgsql – PostgreSQL

11 Mar 2025 09:24

Так я вам выше костыльный вариант привел — но он работает (тот, что с replace).

С другой стороны, я бы обратился к тому, что "выдумал" такую сомнительную схему хранения зоны (и оправдал её хранение в целом) с вопросом, как он собирался с этим работать.

pgsql – PostgreSQL

11 Mar 2025 09:19

Об этом коллега выше пояснил, почему.

pgsql – PostgreSQL

11 Mar 2025 09:18

А по мне так сейчас всё правильно. В результате вы видите значение timestamptz в локальном формате вашего "клиента" — который тоже со смещением +3.

pgsql – PostgreSQL

11 Mar 2025 09:16

... ну и в клиенты, отличные от psql, дополнительно "хозяйничают" со временем при отображении сами ещё. наверное не все, но я настолько часто натыкался в истории чата про это, что для себя запомнил как "если что-то со временем будет непонятно — проверять только в psql". =)

pgsql – PostgreSQL

11 Mar 2025 09:12

Интересно, почему это правило не применяется, если не указать "стандарт" (и применяется если указать несуществующий)...

upd.: Хотя, в первом варианте кажется понятно, почему (потому что эта строка уже в формате ISO 8601, в котором определено как с зонами работать). А вот второй случай уже скорее недоработка PostgreSQL.

pgsql – PostgreSQL

11 Mar 2025 09:10

да, он же принимает указание на offset в американском стандарте, для которого инвертированы значения + и - в указании оффсета.
я тоже каждый раз заново этот момент вспоминаю, т. к. с запросами на самом деле редко работаю как админ, тем более с таймстампами.

вот скажем пример правильного указания смещения GMT+03:00 и сравнения результата с таковым для таймзоны Москвы (в которой у нас смещение тоже GMT+03:00):

postgres=# SELECT '2023-01-02 03:04:05.666'::timestamp AT TIME ZONE 'GMT' AT TIME ZONE 'GMT-03:00';
        timezone
-------------------------
 2023-01-02 06:04:05.666
(1 row)

Time: 2,061 ms

postgres=# SELECT '2023-01-02 03:04:05.666'::timestamp AT TIME ZONE 'GMT' AT TIME ZONE 'Europe/Moscow';
        timezone
-------------------------
 2023-01-02 06:04:05.666
(1 row)

Time: 1,145 ms

pgsql – PostgreSQL

11 Mar 2025 09:03

А если так:

(created_on || replace(offset, 'GMT', ''))::timestamptz

pgsql – PostgreSQL

09 Mar 2025 07:14

Народ, как в домашних условиях можно погонять postgrespro ENT ?
Есть ли такие варианты?

pgsql – PostgreSQL

08 Mar 2025 19:23

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

pgsql – PostgreSQL

08 Mar 2025 18:32

Но это юмор, не принимать все в реальной жизни))

pgsql – PostgreSQL

08 Mar 2025 18:18

Хотите про все шутку:

SELECT 'Дамоклов меч' AS судьба
FROM жизнь
WHERE ответственность > отдых
AND срок_исполнения < CURRENT_TIMESTAMP;

pgsql – PostgreSQL

08 Mar 2025 15:14

тогда забудьте, это долгая история в расте