Мы только начинаем делать эту фичу, и понятно, что до основных игроков на это поле нам пока далеко. Но мы будем рады, если DataGrip начнут использовать для простых кейсов, пока мы добавляем новую функциональность, полируем существующую и поглядываем на то, что умеют конкуренты :)
Привет! У этой ситуации очень непростой бэкграунд.
1. У PostgreSQL в драйвере JDBC нет возможности узнать дефолтную тайм-зону сервера, которая там хранится в конфиг-файле. Просто нет. На гитхабе можно найти соответствующий тикет с огромной дискуссией. Тикет, кстати, закрыли, хотя делать не стали. github.com/pgjdbc/pgjdbc/issues/576
2. Итак, когда DataGrip подключается к базе при помощи jdbc, нужно выставить какую-нибудь тайм-зону. Мы выставляем UTC. Если этого не сделать, то тайм-зона выставится автоматически, и она возьмётся из процесса. То есть, грубо говоря, проставится тайм-зона той машины, откуда запускается DataGrip. Но это еще хуже, чем UTC, потому что пользователь этого не ожидает. У нас раньше именно так и работало и к нам чуть ли не ежедневно приходили пользователи, которые не понимали что происходит. Мы долго думали и решили, что UTC — вариант, вызывающий наименьшее количество проблем.
4. Как же тогда работает DBeaver, если он тоже использует JDBC? А он-то как раз берет таймзону локальной машины, и ничего не знает про тайм-зону сервера, потому что и не может знать (см пункт один). Просто в вашем случае вы запускаете DBeaver из России, и ваша база имеет ту же таймзону по умолчанию. То есть, это просто совпадение.
ИТОГ: Пока в драйвере не сделали возможность узнавать про тайм зону сервера, текущее решение наименее проблемное. А вам надо проставить тайм-зону Москвы во вкладке Options.
Простого способа нет, вот так чтобы раз два. Но есть всякие обходные приколы.
1. Можно попробовать мультикаретки. По-моему, оч удобный способ, если редактор не воткнёт из-за большого количества инсертов.
2. Можно выделить все инсерты, нажать edit as table, скрыть столбец и то, что получилось оптяь экспортнуть в инстерты. К сожалению, имя таблицы придётся вписать заново, а еще через find/replace пофиксить проблемы с квотацией (кажется, что значения не должны квотироваться повторно, но сейчас это так)
Мы только начинаем делать эту фичу, и понятно, что до основных игроков на это поле нам пока далеко. Но мы будем рады, если DataGrip начнут использовать для простых кейсов, пока мы добавляем новую функциональность, полируем существующую и поглядываем на то, что умеют конкуренты :)
Апдейты будут тут: https://youtrack.jetbrains.com/issue/DBE-3852
Мы работаем над новой версией Schema comparison, очень надеюсь, что все что вы описали, будет в 2021.3.
Мы как раз спросили в тикете, что нужно людям: https://youtrack.jetbrains.com/issue/DBE-283
На 2021 пока нет, в 2022 будем думать :)
Ну, или можете сами подправить экстрактор :)
1. У PostgreSQL в драйвере JDBC нет возможности узнать дефолтную тайм-зону сервера, которая там хранится в конфиг-файле. Просто нет. На гитхабе можно найти соответствующий тикет с огромной дискуссией. Тикет, кстати, закрыли, хотя делать не стали.
github.com/pgjdbc/pgjdbc/issues/576
2. Итак, когда DataGrip подключается к базе при помощи jdbc, нужно выставить какую-нибудь тайм-зону. Мы выставляем UTC. Если этого не сделать, то тайм-зона выставится автоматически, и она возьмётся из процесса. То есть, грубо говоря, проставится тайм-зона той машины, откуда запускается DataGrip. Но это еще хуже, чем UTC, потому что пользователь этого не ожидает. У нас раньше именно так и работало и к нам чуть ли не ежедневно приходили пользователи, которые не понимали что происходит. Мы долго думали и решили, что UTC — вариант, вызывающий наименьшее количество проблем.
3. Что делать тем, кому UTC не подходит? Выставлять тайм зону явно, для этого мы сделали UI: intellij-support.jetbrains.com/hc/user_images/D0Mif8Q0HMgqWufc0v2FpQ.png
4. Как же тогда работает DBeaver, если он тоже использует JDBC? А он-то как раз берет таймзону локальной машины, и ничего не знает про тайм-зону сервера, потому что и не может знать (см пункт один). Просто в вашем случае вы запускаете DBeaver из России, и ваша база имеет ту же таймзону по умолчанию. То есть, это просто совпадение.
ИТОГ: Пока в драйвере не сделали возможность узнавать про тайм зону сервера, текущее решение наименее проблемное. А вам надо проставить тайм-зону Москвы во вкладке Options.
1. Можно попробовать мультикаретки. По-моему, оч удобный способ, если редактор не воткнёт из-за большого количества инсертов.
2. Можно выделить все инсерты, нажать edit as table, скрыть столбец и то, что получилось оптяь экспортнуть в инстерты. К сожалению, имя таблицы придётся вписать заново, а еще через find/replace пофиксить проблемы с квотацией (кажется, что значения не должны квотироваться повторно, но сейчас это так)
Помогло?