Fix toDateTime64 saturation doc example (9999 not 2282)

[groeneai]

Changelog category (leave one):

• Documentation (changelog entry is not required)

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

...

Description

The embedded toDateTime64 documentation example for the saturation case SELECT toDateTime64(1546300800000, 3) showed 2282-12-31 00:00:00.000, a stale legacy DateTime64 maximum. The actual output is 9999-12-31 23:59:59.000 (DateTime64 upper saturation is year 9999).

Verified against a real server:

SELECT toDateTime64(1546300800000, 3) AS value, toTypeName(value)

9999-12-31 23:59:59.000   DateTime64(3)

Note: the toDateTime32 doc block in the same file also contains a mislabeled copy of this example (showing 2299-12-31 23:59:59.000); that block is being rewritten separately in #110459, so this PR only touches the genuine toDateTime64 example.

[groeneai]

Pre-PR validation gate (click to expand)

#	Question	Answer
a	Deterministic repro?	Yes — clickhouse-local -q "SELECT toDateTime64(1546300800000, 3)" deterministically returns 9999-12-31 23:59:59.000, not the documented 2282-12-31 00:00:00.000.
b	Root cause explained?	The doc string literal at FunctionsConversion_reg.cpp (toDateTime64 "As decimal with precision" example) hardcoded a stale legacy DateTime64 max (2282-...). DateTime64 upper saturation is year 9999, so the true output is 9999-12-31 23:59:59.000.
c	Fix matches root cause?	Yes — corrected the hardcoded example output string to the actual saturated value. No behavior change.
d	Test intent preserved / new tests added?	N/A (documentation string literal correction, not a code bug; the value is verified against real server output).
e	Both directions demonstrated?	Real server output confirms 9999-12-31 23:59:59.000; the doc now matches.
f	Fix is general across code paths?	The mislabeled copy of this example in the sibling toDateTime32 doc block (showing 2299-...) is being rewritten separately in #110459; this PR only touches the genuine toDateTime64 example to avoid conflict.
g	Fix generalizes across inputs?	N/A (documentation example correction, not a code bug).
h	Backward compatible?	N/A (documentation-only).
i	Invariants and contracts preserved?	N/A (documentation-only).

Session id: cron:clickhouse-worker-slot-1:20260715-055300

[groeneai]

cc @yariks5s — one-line doc fix: the toDateTime64 saturation example showed the stale legacy max (2282-12-31 00:00:00.000); the actual saturated output is 9999-12-31 23:59:59.000. Could you take a look?

[clickhouse-gh]

Workflow [PR], commit [2b50f4d]

Summary: ❌

• Performance Comparison: Performance dashboard

job_name	test_name	status	info	comment
Stateless tests (amd_asan_ubsan, distributed plan, parallel)		FAIL
	04033_tpc_ds_q23	FAIL	cidb
Integration tests (amd_tsan, 3/6)		FAIL
	test_replicated_database/test.py::test_replicated_table_structure_alter	FAIL	cidb, issue

---

AI Review

Summary

This PR corrects the embedded toDateTime64 documentation example to match current saturation behavior for numeric toDateTime64(..., 3) inputs. I traced the current conversion path in src/Functions/FunctionsConversion.h and src/Functions/DateTimeTransforms.h; at scale 3, whole-second numeric inputs clamp against the DateTime64 calendar maximum 9999-12-31 23:59:59 before scaling, so the updated example is consistent with the implementation. I found no remaining review issues in the current diff.

Final Verdict

Status: ✅ Approve

[groeneai]

CI finish ledger — 2b50f4d

Every failure below has an owner. Only CH Inc sync is exempt.

Check / test	Reason	Owner / fixing PR
Stateless tests (amd_asan_ubsan, distributed plan, parallel) / 101 unrelated tests (Code 241)	host-OOM (fleet-wide OvercommitTracker (total) memory limit exceeded, 113 PRs + master, 01:00-04:45 UTC window)	#110503 (ours, open, approved)
CH Inc sync	private ClickHouse Inc sync	CH Inc sync (private, not actionable by us)

This is a 1-line documentation-only change; the distributed plan, parallel job failures are the fleet-wide host-OOM event (unrelated to the diff), owned by fixing PR #110503.

Session id: cron:our-pr-ci-monitor:20260715-140000

[clickhouse-gh]

LLVM Coverage Report

Metric	Baseline	Current	Δ
Lines	85.90%	85.90%	+0.00%
Functions	92.70%	92.70%	+0.00%
Branches	78.00%	78.10%	+0.10%

Changed lines: Changed C/C++ lines covered: 7/7 (100.00%) · Uncovered code

Full report · Diff report