Antalya 26.6: Support for 'time' type in Iceberg

[zvonand]

Changelog category (leave one):

• Improvement

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

Support for 'time' type in Iceberg, read and write (#1761 by @ianton-ru).

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)

Cherry-picked from #1761.

---

Documentation entry for user-facing changes

Solved #1535

This changes time format,.
Was - seconds from midnight:

SELECT * FROM datalake.`namespace.table`

43200

Now - time with microseconds

SELECT * FROM datalake.`namespace.table`

12:00:00.000000

[github-actions]

Workflow [PR], commit [24d1ace]

[zvonand]

@blau-ai

[blau-ai]

CI triage for #2129

Verdict: 8 failing checks → 1 PR-caused (a clang-tidy nit with a one-line fix), 7 pre-existing/infra. The only thing this PR actually broke is the arm_tidy lint. Everything else fails the same way on the base branch antalya-26.6 (run 30468399078 @ 4359a07, which is this PR's merge base) or is a runner/memory infra flake.

---

🔴 PR-caused (1) — needs a fix

Build (arm_tidy) — job log

src/Processors/Formats/Impl/Parquet/PrepareForWrite.cpp:504:20: error: variable 'converted_scale' is not initialized
  [cppcoreguidelines-init-variables,-warnings-as-errors]
  504 |             UInt32 converted_scale;

arm_tidy builds with WERROR=ON, so the clang-tidy cppcoreguidelines-init-variables diagnostic is fatal. In practice converted_scale is always assigned before use (the else throws), so this is a lint-only issue — it does not affect the functional binary — but it blocks the tidy gate.

Suggested fix (one line):

-            UInt32 converted_scale;
+            UInt32 converted_scale = 0;

Note: every non-tidy Build (...) job showed skipping (build-cache reuse), so arm_tidy was the only job that actually compiled the new code — this is the single blocker introduced by the diff.

---

🟡 Pre-existing on the base branch (5) — not caused by this PR

Confirmed by running the same suites on antalya-26.6 @ 4359a07 (the merge base), where they already fail:

Check	Evidence it's pre-existing
Regression {aarch64,release} iceberg_1	Base fails the identical scenarios: sort key timezone (all transforms), iceberg iterator race condition, swarm examples. None touch the Time64/Avro/Parquet code in this PR.
Regression {aarch64,release} iceberg_2	Fails on base too.
Regression {aarch64,release} s3_export_partition	Fails on base (all 4 features).
Regression {aarch64,release} swarms	Fails on base (11/12 features, ~1170 scenarios — swarm services not coming up = infra).
Stateless tests (amd_debug, parallel)	Fails on base. Single failure here is 03634_autopr_input_bytes_estimation → Estimated query execution time (614s) is too long. Maximum: 600 — a slow-runner timeout, unrelated to the diff.

---

🟠 Infra / flaky (2) — safe to re-run

• SQLLogic test (passed on base) — not a correctness regression. The server hit its global memory limit and every query cascaded:

  DB::Exception: (total) memory limit exceeded: would use 3.00 GiB ... current RSS: 25.96 GiB, maximum: 3 GiB
  

  RSS 26 GiB against a 3 GiB limit → the 190,317 "failed tests" are all this one memory-limit cascade, and "total tests < minimum" is the run aborting early. Environmental; re-run should recover.
• Stress test (arm_debug) — failure signature is Timeout exceeded while receiving data from server / Connection refused (localhost:9000) under load. Classic stress flakiness (base failed Stress test (arm_tsan) similarly); nothing in the diff touches server core. Re-run.

---

Bottom line

The Time64 / Iceberg-time change looks clean w.r.t. CI — no new test failures are attributable to it. Only the arm_tidy lint needs the one-line init above; the rest are pre-existing base-branch redness or infra flakes that a re-run (or a base-branch fix) will clear.

I have the one-line fix ready. How would you like it delivered — a direct commit to feature/antalya-26.6/pr-1761, or a separate PR from a blau/* branch? I won't push until you say which.

_{🤖 Generated with Claude Code}

[zvonand]

@blau-ai

[blau-ai]

CI triage

Verdict: 0 failures caused by this PR. Of the red checks: 8 are pre-existing on antalya-26.6 (fail identically without this PR), ~9 are a CI-harness/infra bug (unrelated to any code), and 2 are known flaky/timeout stateless jobs. None of the failures touch the Avro/Parquet/Iceberg time-type code this PR adds.

⚠️ One real gap, though: because of the infra bug below, the integration jobs never reported results, so the new time-type tests this PR adds (test_write_time.py, test_partitioning_by_time) have not actually been validated by CI. See "What still needs to happen" at the end.

---

1. Pre-existing on the base branch — NOT this PR

Check	Evidence
Regression {aarch64,release} iceberg_1 / iceberg_2	Base run 29883716329 (sha 4359a07, 2026-07-22, before this PR) fails the exact same 9 leaf scenarios: swarm examples, iceberg iterator race condition, and 7× sort key timezone/*. Same decisive error in both base and PR: Code: 115. DB::Exception: Unknown setting 'object_storage_cluster'. (UNKNOWN_SETTING) ... SETTINGS use_hive_partitioning=1, object_storage_cluster='swarm'. The regression suite uses a server setting this build doesn't register — a suite/build-version mismatch, not the PR. None of the 9 scenarios is an Avro/Parquet/time-type read/write case.
Regression {aarch64,release} swarms	Fails on base run 29883716329 too (both arches). Catastrophic pass rate (≈1170/1520 scenarios) → environment/suite, not test logic.
Regression {aarch64,release} s3_export_partition	Fails on base run 29883716329 too (both arches).

2. CI-harness / infra failure (praktika + boto3) — NOT this PR, affects all PRs

These jobs died very fast (2–3 min) in the result-upload post-run hook, before/independent of any test verdict. Identical stack in every one:

File ".../ci/praktika/.../s3.py" ... client.put_object(...)
botocore.exceptions.ParamValidationError: Parameter validation failed:
Unknown parameter in input: "IfMatch", must be one of: ACL, Body, Bucket, ...
##[error]Process completed with exit code 1.

praktika now sends a conditional-write IfMatch header that the boto3 installed on the runners doesn't accept. Affected checks: Install packages (arm_release), SQLLogic test, SQLStorm test, Stress test (arm_debug), Stress test (arm_release), Integration tests (arm_binary, distributed plan, 1/4 & 3/4), Stateless tests (arm_binary, sequential). For the two integration shards, no test is reported as failing — the job crashed in the upload step, so no iceberg/time test failure is implicated. (All of these passed on the base branch's newer run, consistent with this being a recently-introduced harness regression, not the PR.) Grype Scan is also red but its own output says "Completed with 0 high/critical vulnerabilities" — no real security finding; treat as the same non-code/gate noise.

Fix is infra-side (pin/upgrade boto3 on runners, or stop sending IfMatch), not a change to this PR.

3. Known-flaky / debug-timeout — NOT this PR

• Stateless (amd_debug, parallel) — 3 failed: 04033_tpc_ds_q96, 04033_tpc_ds_q24 (both "Timeout! Killing process group"), 00009_uniq_distributed (rerun Runs: 3, Failed: 0).
• Stateless (amd_debug, distributed plan, s3 storage, parallel) — 5 failed: 04033_tpc_ds_q14 (900s cap), 03518_alter_logical_race, plus 03375_bloom_filter_token_has_hasAny_const_array, 03779_materialized_view_database_context, 01854_HTTP_dict_decompression — all three pass on CI's own rerun (Failed: 0). Broken-marked 03441_deltalake_clickhouse_virtual_columns is flaky S3 (Code 742), and the PR doesn't touch DeltaLake.

None relate to Avro/Parquet/Iceberg/time.

---

What still needs to happen

1. Nothing to fix in the PR code based on current CI — no failure is attributable to it.
2. The feature is not yet CI-validated. The new time-type integration tests live in the arm_binary integration shards that crashed in the infra upload hook, so they never produced a verdict. Once the praktika/boto3 IfMatch issue is resolved on the runners, re-run the Integration checks so test_write_time.py and test_partitioning_by_time actually execute and confirm the read+write path.
3. The pre-existing object_storage_cluster / swarms / s3_export regression failures are a separate, base-branch-wide problem to be tracked independently of this PR.

_{Triage from CI evidence only (no local build/test in this environment). Base comparison: run 29883716329. If you'd like, I can open a tracking issue for the praktika IfMatch infra bug or dig into any specific job.}