ClickHouse / ClickHouse/clickhouse-go
The use of local timezone in DateTime conversion is inconsistent with CLI client
- Dominant language
- Go
- Stars
- 3.3k
- Forks
- 684
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 14
Description
DateTime parsing defaults to using client zone (time.Local)
https://github.com/ClickHouse/clickhouse-go/blob/8d87c2326315f4448085aefc95d5c040954ca235/lib/column/datetime64.go#L314
I believe this was introduced in 0704ee8 ('align date and datetime handling with spec'); maybe earlier as #291 before that had mentioned 'it's better to use local timezone than UTC'
CLI client defaults to server timezone unless you specify `--use_client_time_zone=true`, for example:
```sh
clickhouse client -h server.local -q "INSERT INTO a VALUES ('2025-02-07 00:00:00')"
TZ=CET clickhouse client -h server.local -q "INSERT INTO a VALUES ('2025-02-07 00:00:00')" --use_client_time_zone=true
clickhouse client -h server.local -q "SELECT * FROM a"
```
gets me only the second timestamp shifted into the CET timezone
Should the library match the CLI?
What is the specification mentioned in 0704ee8, maybe that would help explain the motivation?
Or is it issue #135 which resulted in PR #291?
Contributor guide
Research direction
Start with lib/column/datetime64.go around the linked conversion code, then inspect commit 0704ee8 and issues #135 and #291 for the specification and rationale behind the current time.Local behavior. Compare that behavior with the CLI examples in this issue. Done means the library’s timezone semantics are resolved against the CLI or specification and the relevant behavior is documented and covered by tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend, databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100