Cherry-pick: Respect use_client_time_zone for string datetime literals parsed on the server

[zvonand]

Cherry-picked from ClickHouse#109051.

Changelog category (leave one):

• Bug Fix (user-visible misbehavior in an official stable release)

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

Fixed use_client_time_zone being ignored for DateTime/DateTime64 string literals interpreted on the server (asynchronous INSERT, SELECT literals). The client now propagates its local time zone as session_timezone when use_client_time_zone is enabled, so server-side parsing matches the synchronous INSERT path (ClickHouse#109051 by @groeneai).

CI/CD Options

Exclude tests:

• Fast test
• Integration Tests
• Stateless tests
• Stateful tests
• Performance tests
• All with ASAN
• All with TSAN
• All with MSAN
• All with UBSAN
• All with Coverage
• All with Aarch64
• All Regression
• Disable CI Cache

Regression jobs to run:

• Fast suites (mostly <1h)
• Aggregate Functions (2h)
• Alter (1.5h)
• Benchmark (30m)
• ClickHouse Keeper (1h)
• Iceberg (2h)
• LDAP (1h)
• Parquet (1.5h)
• RBAC (1.5h)
• SSL Server (1h)
• S3 (2h)
• S3 Export (2h)
• Swarms (30m)
• Tiered Storage (2h)

[github-actions]

Workflow [PR], commit [d34aa79]

[zvonand]

@blau-ai

[blau-ai]

CI triage for #2047

Verdict: not green. 1 failure is PR-caused, the rest are pre-existing / infra / flaky.

The one real, PR-caused failure is the new test this PR adds — 04401_async_insert_use_client_time_zone. Everything else (Grype, S3Export regression, DCO, the other stateless tests, the aggregate gates) is unrelated to a client-side timezone change.

---

🔴 PR-caused — 04401_async_insert_use_client_time_zone

Fails consistently: 50/50 runs in Stateless tests (amd_asan, flaky check), and it also shows up in the failed-test list of the regular stateless jobs (amd_binary, ParallelReplicas and amd_binary, old analyzer, DatabaseReplicated). Not flaky — deterministic.

Decisive diff (reference vs. actual):

 flag_sync            1500036000     <- sync rows OK
 set_sync             1500036000
-flag_async           1500036000     <- expected (client TZ)
+flag_async           1500003600     <- actual   (server TZ)
-reset_default_async  1500036000
+reset_default_async  1500003600
-set_async            1500036000
+set_async            1500003600
-settings_async       1500036000
+settings_async       1500003600
 reset_async matches server tz   1

Reading it: the literal 2017-07-14 05:40:00 under TZ=America/Hermosillo (UTC‑7, no DST) should map to 1500036000. The sync rows (parsed client-side) are correct. Only the async rows are wrong, all off by exactly 9h (1500036000 → 1500003600), i.e. 05:40:00 interpreted in the server timezone (~UTC+2 in this CI env) instead of the client's. So the session_timezone the fix seeds in ClientBase::processParsedSingleQuery is not reaching the server-side async-INSERT VALUES parse in the antalya‑25.8 build. The reset_async matches server tz = 1 invariant still holds, which confirms the propagation only misfires when the client zone should be applied.

Why this isn't a bad cherry-pick: the diff here is byte-for-byte identical to upstream ClickHouse/ClickHouse#109051, which is green upstream. The capture in Client::connect() is also correctly ordered — and with use_client_time_zone=1 the server-TZ switch (Client.cpp:563) is skipped entirely, so client_local_timezone should hold the client OS zone. The fix works for sync but not async here ⇒ this is a 25.8-vs-26.x runtime divergence in the async-insert path, not a merge/port defect.

Suggested next step (needs a build — I can't run ClickHouse in this container, so this is a lead, not a validated fix):

1. Repro locally: TZ=America/Hermosillo clickhouse-client --use_client_time_zone=1 -q "INSERT INTO t SETTINGS async_insert=1, wait_for_async_insert=1 VALUES ('2017-07-14 05:40:00')" and check toUnixTimestamp — expect it to come out in server TZ.
2. Confirm whether session_timezone is actually transmitted for that async insert — check system.query_log / system.asynchronous_insert_log Settings for the query. The fix sets it on client_context right after applySettingsFromServerIfNeeded(); verify the antalya‑25.8 async-insert send path (and the server-side AsynchronousInsertQueue VALUES parse) reads that context. In 26.x it does; in 25.8 it likely captures the timezone before session_timezone is applied.
3. Strong possibility: antalya‑25.8 is missing a prerequisite upstream commit that Respect use_client_time_zone for string datetime literals parsed on the server ClickHouse/ClickHouse#109051's async propagation depends on (settings transmission / async-insert context handling). Worth diffing the async-insert setting-propagation code between the two branches before writing a 25.8-specific hook.

I have not pushed anything. Once we have a candidate fix (or decide to gate the async cases for 25.8), I can open a blau/* PR so CI validates it — just say the word, or tell me to commit directly to releasy/port/pr-109051-a8a99c.

---

🟡 Not PR-caused

Check	Classification	Evidence
DCO	Housekeeping	The port commit b0005d3 (a re-used upstream merge commit) has no Signed-off-by: trailer. Needs a sign-off/rebase or a maintainer override; not a code issue.
Grype Scan ×3 (keeper, server, server-alpine) + GrypeScanKeeper/GrypeScanServer jobs	Infra / pre-existing	CVE scans of the built Docker images. A client-side C++ timezone change cannot affect image contents; these fail branch-wide independent of this PR.
RegressionTestsRelease / S3Export (part) & Regression x86 s3_export_part (14/85 scenarios)	Pre-existing / flaky infra	Server-side S3 export against MinIO — unrelated to client literal parsing. Note the sibling regressions passed: Regression x86 swarms (1488 ok) and s3_export_partition (7/7 ok).
Other stateless failures besides 04401: 03321_clickhouse_local_initialization_not_too_slow_even_under_sanitizers (timing/perf), 01710_projection_additional_filters, 04299_constraint_subst_correlated_subquery_root, 04340_datalake_schema_deep_recursion, 04409/04410_explain_actions_secret_args	Pre-existing / flaky on antalya‑25.8	None touch client timezones; this PR only changes programs/client/Client.cpp + src/Client/ClientBase.{cpp,h} + the new test.
FinishCIReport, PR	Aggregate gates	Red only because of the checks above; no independent error.

Bottom line: the port applied cleanly, but the feature it backports is not fully functional for async inserts on antalya‑25.8 — that's the only thing this PR needs to resolve before merge. The remaining red is noise you'd see on the base branch too.

_{🤖 Automated CI triage by @blau-ai. I can't build/run ClickHouse in-container; the async root cause above is a lead to validate on a build, not a tested conclusion.}

[zvonand]

@blau-ai

[blau-ai]

CI triage for #2047

Verdict: none of the failures are caused by this PR's code. The PR's own new tests (02737_session_timezone, 04056_mutation_session_timezone_datetime_literals, 04057_async_insert_session_timezone, 04401_async_insert_use_client_time_zone) all passed, and every failing stateless test is an unrelated datalake/analyzer test that fails identically across all shards. Breakdown of the failing checks:

• 1 actionable (process, not code): DCO
• 2 infra/flaky: Build (amd_release), Regression aarch64 swarms
• ~8 stateless shards: all pre-existing/broken/flaky tests unrelated to timezone
• PR is just the aggregate gate rolling up the above.

---

1. DCO — PR-related (only real action item)

b0005d3 Merge pull request ClickHouse#109051… — Sign-off not found
d34aa79 Backport ClickHouse#100647… — Skipped: sign-off not required for members ✅

The backport branch carried the upstream merge commit b0005d3 as a separate commit, and it has no Signed-off-by line (its author is an upstream contributor, not an Altinity org member, so it isn't auto-exempted). This is commit-metadata only — nothing wrong with the code.

Fix options (any one):

• Merge this PR with "Squash and merge" — the merge commit disappears and DCO becomes moot.
• Or re-create the backport without the upstream merge commit (cherry-pick just the change), so only the signed-off d34aa79 remains.
• Or a maintainer overrides the DCO status.

I did not rewrite/force-push the branch to fix this (history rewrite on a shared PR branch is outside my permissions).

2. Build (amd_release) — infra, re-run

Job got terminated with an error, exit code [-15] after 2h4m47s

Exit -15 = SIGTERM, i.e. the runner was killed (timeout / spot reclaim), not a compile error. Every other build target — amd_binary, amd_debug, amd_asan, arm_binary, arm_release — passed, so the code compiles cleanly. Just re-run this job.

3. Regression aarch64 swarms — flaky

aarch64: 12 features (10 ok, 2 failed), 1520 scenarios (1487 ok, 1 failed, 32 xfail)
x86: 12 features (12 ok), 1520 scenarios (1488 ok, 32 xfail) ✅

Regression x86 swarms is fully green; only the aarch64 run dropped 1 scenario out of 1520. This is the Altinity clickhouse-regression swarm suite (cluster behavior) — no relation to the client/server DateTime-parsing changes in this PR. Classic flake; re-run the aarch64 swarms job.

4. Stateless tests (all failing shards) — pre-existing / broken / flaky, not PR-related

The same handful of tests fails across every shard, and none touch DateTime / session_timezone / async-insert code:

Test	Type	Why it fails
04340_datalake_schema_deep_recursion	FAIL (every shard)	Datalake test; deterministic pre-existing failure on the branch
03441_deltalake_clickhouse_public_datasets / _virtual_columns	BROKEN	DeltaLake tests against external/public datasets (environment/network)
01710_projection_additional_filters	FAIL	Projection test, unrelated
04299_constraint_subst_correlated_subquery_root	FAIL	Constraint/subquery test, unrelated
04409_explain_actions_secret_args / 04410…_secondary	FAIL (old-analyzer shard)	EXPLAIN QUERY TREE is only supported with a new analyzer — old-analyzer incompatibility, not this PR

That the identical set fails on shards that never exercise this PR's code path (e.g. arm_binary, parallel failing only on 04340) confirms these are branch-level pre-existing/environmental failures, not regressions introduced here. (Note: several of these show up as GitHub "success" jobs whose S3 test report still logs the failure — the CI's flaky-retry logic passed the job while recording the raw failure.)

---

Bottom line

The port itself is healthy: it builds on every non-infra target and its four dedicated timezone tests pass. The only thing blocking a clean CI is DCO, which is a merge-commit sign-off issue fixable by squash-merging or dropping the upstream merge commit — not a code change. The build and swarms failures are infra/flake (re-run), and the stateless failures are pre-existing datalake/analyzer tests unrelated to this backport.