нужные?
SELECT
toDateTime(10000, 'Europe/London') as lon_time,
toDateTime(10000, 'Europe/Moscow') as mos_time
и первое и второе отдают одинаковый результат - 1970-01-01 02:46:40
а вы где проверяете? в clickhouse-client вроде норм SELECT toDateTime(10000, 'Europe/London') AS lon_time, toDateTime(10000, 'Europe/Moscow') AS mos_time ┌────────────lon_time─┬────────────mos_time─┐ │ 1970-01-01 03:46:40 │ 1970-01-01 05:46:40 │ └─────────────────────┴─────────────────────┘
клиент - да, а вот в датагрипе нет, разве он может влиять?
датагрип на своей стороне конвертит в свою таймзону поидее
очень странное поведение, но похоже вы правы SELECT toString(toDateTime(10000, 'Europe/London')) as lon_time, toString(toDateTime(10000, 'Europe/Moscow')) as mos_time отдает верный результат
Надо просто понять что TZ это просто метаданные колонки (и даже не колонки в таблице) , а колонки select-а и insert-а JDBC драйвер 100500 раз переделали уже, в будущем JDBC драйвер будет показывать время в TZ колонки селекта а не в TZ jvm. но JDBC драйвер на самом деле ничего не показывает, он передает в java как число секунд, а java при рендеринге в строку, конвертирует в TZ jvm в КХ все значения DateTime лежат в UTC (число секунд от 1970), TZ это просто намек как парсить и рендерить строки. дефолтная TZ задается 3 способами, в конфиге, через env переменную TZ, через таймзону сервера (линукс)
Обсуждают сегодня