-
Notifications
You must be signed in to change notification settings - Fork 556
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Date/Date32 is wrong when written with time.Time parsed from local timezone. #693
Comments
Will take a look but Date is not locale aware - its just days since 1970. Think you want https://clickhouse.com/docs/en/sql-reference/data-types/datetime |
The behavior of v2 version is not consistent with lower versions of clickhouse-go. In v1 versions, CH date will be the same with time.Time in golang even if the zone of time.Time is not UTC. |
Many differences with v1. Complete rewrite. No effort to have the same behaviour - since a lot of what it did was wrong e.g. loss of precision on types. The argument here is should the date be persisted in the tz it was sent i.e. should the date be interpreted as-is or its true UTC time stored (since the column has no notion of timezone). In my mind, both are fine and this is a ch-go decision. Either way, we need to be consistent with our date types and document. |
Fixed in |
I'll update, add test and PR. thanks @ernado |
your test on 0.47.2 ch-go (albeit simplified) The following will fail with
The correct date is now stored but strictly, the inserted date and retrieved date are different @ernado This might be the behavior we intend. Obviously if I change the test to
|
Issue description
Date/Date32 is wrong when written with time.Time parsed from local timezone.
Example code
Error log
My local timezone is
Asia/Shanghai
, so is ClickHouse and Linux System. After insertion, the Date in CH is expected to be2022-01-12
, but it is2022-01-11
actually.Configuration
OS: Docker, Ubuntu20.4
Interface:
database/sql
Driver version: v2.2.0
Go version: go version go1.18.1 linux/amd64
ClickHouse Server version: v21.10
The text was updated successfully, but these errors were encountered: