ClickHouse / ClickHouse/clickhouse-go

The use of local timezone in DateTime conversion is inconsistent with CLI client

Open
#1,492 1 comment 0 reactions 0 assignees View on GitHub
discuss
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.