Всем здравствуйте! Кто может мне объяснить, почему select timezone() as tz, toDate(0)

as date0, toDateTime(toDate(0)) as datetime0
возвращает
Europe/Moscow 1970-01-01 1970-01-02 00:00:00
Почему datetime0 2-е Января?
Версия 22.10.7.13.

https://fiddle.clickhouse.com/7b2a230d-b600-407a-a5f1-6e28a00e471d похоже какой то ньанс или баг с конвертацией из Date в DateTime

Да, вот бы знать, нюанс это или баг?...

issue На github заведите...

Да какой ещё баг. UTC это Лондон. Время начинается с 0. В Москве такое время не существует.

Это не баг. Время datetime 0 не существует в Москве.

это в Канаде такого времени еще не существует... ;) а в Москве это UTC+3 / UTC+4 (когда было летнее время) и сейчас просто UTC+4 (пока очередной нелюдь в думе не захочет себя в историю записать) и соответственно 0 unixtime должно по идее быть 1970-01-01 03:00:00 UTC+3 посмотри вот сюда https://fiddle.clickhouse.com/a2e3b3c0-8e63-4cb7-89a5-74a946760028 почему toDateTime(toDateTime(0), 'Europe/Moscow'): 1970-01-01 03:00:00 нормально сконвертировал 0 DateTime в +3 UTC но при этом если на вход Date toDateTime(toDate(0), 'Europe/Moscow'): 1970-01-02 00:00:00 то уже конвертация идет как то по другому, округление какое то? то есть в чем разница в toDateTime когда в него прилетает Date и DateTime первым параметром?

Так они хотят 19700000000 по Москве, это -4 часа в utc

они хотят ответ на вопрос > select timezone() as tz, toDate(0) as date0, toDateTime(toDate(0)) as datetime0 > возвращает > Europe/Moscow 1970-01-01 1970-01-02 00:00:00 > Почему datetime0 2-е Января? toDate(0) тут по идее внутренний 0 (кол-во дней с 1970-01-01), с систеным TZ UTC+3 ? так? https://clickhouse.com/docs/en/sql-reference/data-types/date DateTime это unixtime 32bit внутри плюс системная TZ, либо явно TZ в типе задана и по идее она там тоже должна только для вывода и парсинга строк использоваться, но не при конвертации https://clickhouse.com/docs/en/sql-reference/data-types/datetime#usage-remarks при попадании на вход в toDateTime поля Date без указании TZ, происходит конвертация... из внутреннего представления Date 0 + системная TZ. в во внутренее представление DateTime - unixtime + системная TZ и вот кажется что внутреннее представление toDate тут по особому интерпретируется то есть при переводе из 0 дней в Date типе во внутренний unixtime типа DateTime оно либо должно учитывать системный TZ либо игнорировать его (потому что оба типа без TZ) выглядит так, что игнорируется потому что вот тут https://fiddle.clickhouse.com/ceb038a4-8b10-43d2-ad6f-c70a8a566077 поведение не изменяется при смене серверной timezone но как то странно, как именно тогда получается 1970-01-02 ?

Там -3600*4 то округляется в 0 то в 1. По разному. Там и 2106 можно получить

откуда -3600*4 то взялось? если в 1971 было -3600*3? и это при конвертации toDate(0) в DateTime представление? почему тогда при изменении timezone конвертация toDate(0) не поменялась? если внутри Date это все равно будет 0? потому что кол-во дней для toDate(0) это все равно 0 для UTC+3 таймозоны в днях, разве не так?

2 января, потому что это сплошное undefined behaviour. Если бы там было 42 февраля 1985 года, я бы точно также не удивлялся. И это не баг. ты зря думаешь об этом как о числах uint32 / uint16. LUT таблица это не формула. toDateTime(toDate(0), 'Asia/Tokyo'): 2106-02-07 06:28:16

а какая версия? какой SELECT timezone() ? а то у меня все время другое значение

какой-то старый КХ. но это все не важно. Оно работает как и задумано. Если сильно надо, то надо использовать datetime64