Dale McDiarmid

We agreed to this. See https://github.com/ClickHouse/clickhouse-go/issues/719

Thanks @leonidboykov i'll need to dig into this as I'm not certain we get the default value back over the native protocol (@genzgd do you know?) - the initial INSERT...

@leonidboykov so this information isn't available or returned by the native protocol by default. We'll therefore need to issue a precursor query to DESCRIBE the table, prior to any INSERT....

I'll put a test together for this to illustrate but I don't think clickhouse-go is considering the Locale of the column itself if its not explicitly set in the column...

Ok, behaviour varies but v2 is correct I believe. v1 is broken but not as the issue suggests. This indeed seems to differ from ClickHouse-client. The driver is parsing the...

So currently, `2022-07-20 17:42:48` is inserted as `1658338968129` i.e. UTC. When you read it back, it's rendered in UTC+8. We have a few options here at insert time: 1. Use...

This is further complicated by the fact column TZ info is not returned over HTTP even if using the native format (and the column has a tz) https://github.com/ClickHouse/ClickHouse/issues/38209

@zhoufuke we discussed and agreed on a specification for all clients - https://github.com/ClickHouse/clickhouse-go/issues/719 In summary, we will revert to the tz of the client - consistent with your desired behaviour....

@DGuang21 it wont let me assign this. Noted the issue that's relevant to your work above.

We will only support `YYYY-MM-DD HH:MM:SS Z` or `YYYY-MM-DD HH:MM:SS`. For DateTime64 we would also support up to nano seconds with this format e.g. `YYYY-MM-DD HH:MM:SS.XXXXXXXXX` Z