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 [f7c3084]

[zvonand]

@blau-ai

[blau-ai]

CI triage

Verdict: 2 red checks — 0 are a real code problem in this port. 1 is a metadata/sign-off issue, 1 is an unrelated flaky test.

The PR and the S3 Fast test/Config Workflow/Finish Workflow rows are just aggregate mirrors of the two checks below — no separate failures. Everything else is skipping.

---

1. DCO — ❌ metadata, PR-related but not a code issue

All commits are incorrectly signed off … 82e5b3d "Merge pull request ClickHouse#109051 from groeneai/fix-async…" — Sign-off not found

The cherry-picked commit message has no Signed-off-by: line. This is purely a commit-metadata gate, not a build/test problem.

Fix (needs a human — I don't force-push, and this is the PR head branch, not a blau/* branch):

git checkout releasy/port/pr-109051-a7e5ac
git commit --amend --signoff --no-edit
git push --force-with-lease origin releasy/port/pr-109051-a7e5ac

(If you'd rather not amend, DCO also accepts a separate empty remediation commit — see the "add remediation commit" option in the check output. Amending the single commit is cleaner here.)

---

2. Fast test — ❌ one flaky test, not related to this PR

Failing test: 03221_merge_profile_events (result diff, not the code this PR touches):

--- reference
+++ stdout
 Vertical  1  20000  1  2  480000  1  1  1  1  1  1  1  1
-Vertical  1  20000  1  2  480000  1  1  1  1  1  1  1  1
+Vertical  1  20000  1  2  480000  1  1  1  1  1  1  0  1

The only differing column is the 12th value — ProfileEvents['UserTimeMicroseconds'] > 0. For the small 20 000-row vertical merge it returned 0, i.e. the merge was fast/idle enough that accounted user-CPU time rounded to 0. That's an inherent timing/resource-accounting flake in this test (it asserts several …Milliseconds > 0 / CPU-time counters are non-zero), and it has nothing to do with client time-zone propagation.

Evidence it isn't this PR:

• The diff only touches programs/client/Client.cpp and src/Client/ClientBase.{cpp,h} (client-side session_timezone seeding) plus a new stateless test. Nothing here influences merge profile-event accounting.
• The PR's own new test 04401_async_insert_use_client_time_zone was [ SKIPPED ] in Fast test (it's tagged no-fasttest), so the failure is definitely not from this port's additions.

Next step: safe to re-run ("Fast test" only). If it recurs, it's a pre-existing flake in 03221_merge_profile_events worth a separate timing-tolerance fix, independent of this PR.

---

Note on validation of the port itself

The new test that actually exercises this fix (04401_async_insert_use_client_time_zone) is no-fasttest, and the Stateless tests … jobs are all skipping in this run — so the port's own behavior hasn't been executed by CI yet. Once DCO is green and the Fast test re-run passes, it's worth making sure the stateless suite runs so 04401 actually validates the change.

[zvonand]

@blau-ai

[blau-ai]

CI triage

Verdict: exactly one failure is caused by this PR — the new test 04401_async_insert_use_client_time_zone that this cherry-pick adds, and it fails deterministically (not flaky). Everything else red is either the DCO sign-off check (a process issue on the cherry-picked upstream merge commit) or unrelated pre-existing/environmental test failures in the heavy s3 / DataLake configs. The PR check is just the aggregate gate rolling those up.

---

1. 04401_async_insert_use_client_time_zone — ❌ PR-caused, deterministic

Fails in every parallel stateless job (amd_asan 1/2 & 2/2, amd_debug, amd_binary ParallelReplicas & old-analyzer/DatabaseReplicated, arm_binary) and 50/50 runs in the amd_asan, flaky check.

Decisive diff (flaky check, job):

 @@ -1,7 +1,7 @@
-flag_async           1500036000     ← expected (client tz, America/Hermosillo = UTC-7)
+flag_async           1500003600     ← actual   (server tz)
 flag_sync            1500036000     ← sync insert is correct
-reset_default_async  1500036000
-set_async            1500036000
+reset_default_async  1500003600
+set_async            1500003600
 ...

What this means: the synchronous inserts (parsed client-side) get the correct client-timezone instant 1500036000; every asynchronous insert instead lands on the server-timezone instant 1500003600. In other words, the client-time-zone → session_timezone propagation that this PR adds has no effect on the async path in this build.

It is not a bad cherry-pick. The port includes all 5 upstream files, and the Client.cpp / ClientBase.cpp / ClientBase.h hunks are byte-identical to upstream ClickHouse#109051. The same code is green on upstream master. So the gap is on the server/branch side, specific to stable-25.8. Leading hypotheses:

• The server-side half of the feature — async-INSERT VALUES parsing honoring session_timezone — is present on master but missing on stable-25.8, so a client-only backport is insufficient; or
• On 25.8, client_local_timezone comes out empty (DateLUT::serverTimezoneInstance().getTimeZone() at connect() time doesn't yet reflect the client TZ), so the guard if (!client_local_timezone.empty() && …) skips the propagation — which would produce exactly this symptom (async falls back to server tz).

Suggested next steps (I did not push anything):

1. On stable-25.8, run an async INSERT with an explicit SETTINGS session_timezone='America/Hermosillo' and a DateTime string literal — does the stored instant respect that zone? If no, the server-side change must be backported alongside this client change.
2. Confirm client_local_timezone is actually populated on 25.8 (log/inspect it at connect()).
3. Worth pinging the original author (@yariks5s / groeneai) on which upstream commit the server-side behavior depends.

If you'd like, I can dig into the 25.8 async-insert path and prepare either the missing server-side backport or a test adjustment on a blau/* branch — say the word and tell me which delivery you prefer.

2. DCO — ⚠️ not a code failure (process)

The cherry-picked upstream merge commit 82e5b3d has no Signed-off-by line; the merge commit 753e536 is fine. Fix: re-sign that commit (git commit -s --amend / rebase with sign-off) or waive DCO for this backport per your normal port policy — common for ports of upstream merge commits. (I can't amend/force-push under my permissions.)

3. PR — aggregate gate

Red only because of the stateless jobs above. No independent action.

4. Other stateless failures — ✅ not PR-related

The multi-failure parallel jobs consistently also fail tests in subsystems this PR never touches (it only changes client-side timezone handling in Client.cpp / ClientBase.*):

• 03441_deltalake_clickhouse_virtual_columns, 03441_deltalake_clickhouse_public_datasets, 04340_datalake_schema_deep_recursion (DeltaLake / DataLake)
• 04299_constraint_subst_correlated_subquery_root, 01710_projection_additional_filters
• 03579_create_table_populate_from_s3, 04409_explain_actions_secret_args, 04410_explain_actions_secret_args_secondary

A client-timezone change cannot affect DeltaLake schema recursion, projections, or EXPLAIN secret-arg masking — these are pre-existing/environmental failures in the s3-storage / DatabaseReplicated / DataLake configs. Recommend confirming against a recent stable-25.8 base run and re-running; they shouldn't block on this PR's account.

---

Bottom line: fix the real one — 04401 (the async path isn't picking up the client timezone on 25.8, almost certainly a missing server-side prerequisite or an empty client_local_timezone) — and clear DCO. The remaining reds are noise from this PR's perspective.

_{🤖 Generated with Claude Code · evidence: run 29609649541}

[zvonand]

@blau-ai

[blau-ai]

CI triage — PR #2046 (cherry-pick of upstream ClickHouse#109051)

Verdict: 2 red signals, and neither points at a code defect. DCO is PR-attributable but it's a missing sign-off (process, not code); everything else is pre-existing / flaky / infra. The fix itself looks healthy — all four session_timezone tests it adds/updates pass, including under CI's randomized --session_timezone.

---

1. DCO — ⚠️ PR-attributable (process, not code) — needs your action

DCO is ACTION_REQUIRED. The head commit f7c3084 has no Signed-off-by: trailer (it only carries Co-Authored-By: Claude Fable 5). The cncf/dco2 app requires every commit to be signed off.

Fix (requires the branch author — I can't force-push):

git commit --amend -s          # adds "Signed-off-by: Andrey Zvonov <...>"
git push --force-with-lease origin releasy/port/pr-109051-a7e5ac

The sign-off name/email must match the commit author. No code change is involved.

2. PR (aggregate gate) — derived, not an independent failure

This is the roll-up check; it's red only because the checks below are. It clears once they do.

3. Stateless tests — not PR-caused (infra + flaky)

Only 1 of 7 flagged stateless shards actually failed its GitHub Actions job: Stateless tests (amd_binary, ParallelReplicas, s3 storage, parallel) (job 88177533418). The failing tests there are unrelated to DateTime/timezone handling:

• 03441_deltalake_clickhouse_public_datasets, 03441_deltalake_clickhouse_virtual_columns, 04340_datalake_schema_deep_recursion — AWS S3 network/infra. The log shows:

  Code: 742. DB::Exception: Received DeltaLake kernel error … Generic S3 error: Error performing GET https://s3.eu-central-1.amazonaws.com/clickhouse-public-datasets/…/_last_checkpoint … after 10 retries … HTTP error: error sending request (DELTA_KERNEL_ERROR)

  These tests are tagged no-fasttest: Depends on AWS; the runner couldn't reach the public-dataset bucket.

• 01710_projection_additional_filters — result diff 3 vs 23. This test runs with parallel_replicas_local_plan=1, parallel_replicas_support_projection=1; the mismatch is ParallelReplicas + projection nondeterminism, independent of this PR.

• 04299_constraint_subst_correlated_subquery_root — constraint/analyzer test, unrelated to the diff.

The other six flagged shards (amd_debug parallel, arm_binary parallel, amd_asan distributed plan 2/2, old analyzer DatabaseReplicated, AsyncInsert, distributed plan s3) report Failed: 1–3 in their S3 status line but their Actions jobs are green — i.e. those single failures passed on retry (flaky), not real regressions.

---

Why I'm confident the fix is sound

The diff changes DateTime/DateTime64 serialization globally (resolving the effective timezone via DateLUT::instance() when no explicit tz is set). If that were wrong, DateTime output would break broadly under CI's randomized --session_timezone fuzzing. Instead:

• The four tests this PR adds/updates all pass in the failing shard, under --session_timezone values like America/Mazatlan:
  • 02737_session_timezone → [ OK ]
  • 04056_mutation_session_timezone_datetime_literals → [ OK ]
  • 04057_async_insert_session_timezone → [ OK ]
  • 04401_async_insert_use_client_time_zone → [ OK ]
• Fast test: Failed: 0. Unit tests (asan), all Integration tests shards, AST fuzzer, BuzzHouse, Stress test, both Build matrices, and Regression (Parquet/Iceberg) are green.

Recommended next steps

1. DCO: amend f7c3084 with -s and force-push (author action, per above).
2. Stateless: re-run the ParallelReplicas, s3 storage, parallel shard — the DeltaLake failures are transient AWS reachability. If 01710_projection_additional_filters persists, it's a pre-existing ParallelReplicas/projection issue on stable-25.8, not something introduced here.

No code changes are needed from me for this PR. Happy to dig further into the 01710 ParallelReplicas diff against the base branch if useful.

[mkmkme]

Antalya 25.8 is handled by #2047, removing from the project