Regenerated toDateTime64 saturation doc example shows 2299-12-31 but actual output is 9999-12-31

[clickgapai]

Found via ClickGap automated review. Please close or comment if this is incorrect or needs adjustment.

Describe what's wrong

The toDateTime64 documentation example claims SELECT toDateTime64(1546300800000, 3) yields 2299-12-31 23:59:59.000, but the same build actually returns 9999-12-31 23:59:59.000 (DateTime64 upper saturation is year 9999, not the pre-extension 2299).

Root cause: FunctionsConversion_reg.cpp:1332 hardcodes 2299-12-31 23:59:59.000 (the legacy DateTime64 max) as the expected output for a large-integer saturation case whose real result is 9999-12-31 23:59:59.000.

Why we believe this is a bug: PR description claims all examples were 'regenerated from the actual server output' and explicitly lists 'toDateTime64 saturation' as corrected; the edit changed the value from the old 2282-12-31 00:00:00.000 to 2299-12-31 23:59:59.000, but the true saturation value is 9999-12-31 23:59:59.000.

Affected locations:

• src/Functions/FunctionsConversion_reg.cpp:1332 — toDateTime64 'As a decimal with precision' example, second output row (saturation)

Impact: Documentation readers of toDateTime64 see an incorrect saturation result. Cosmetic/informational only; no SQL-observable behavior is affected. Directly contradicts the PR's stated 'regenerated from actual output' methodology.

Does it reproduce on most recent release?

Likely yes — see testability note in additional context.

How to reproduce

clickhouse local -q "SELECT toDateTime64(1546300800000, 3) AS value, toTypeName(value)"  -- observe 9999-12-31 23:59:59.000, not the documented 2299-12-31 23:59:59.000

Expected behavior

doc currently shows: 2299-12-31 23:59:59.000  (should be: 9999-12-31 23:59:59.000)

Error message and/or stacktrace

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

Additional context

Open risks:

• Other regenerated example VALUES were spot-checked (toDateTime64 first row=2025-01-01, UUIDv7ToDateTime=08:30:29.048, subtractQuarters, multiplyDecimal, JSONExtractKeysAndValuesRaw) and all matched actual output; only this saturation row is wrong.

Suggested fix: Replace 2299-12-31 23:59:59.000 at FunctionsConversion_reg.cpp:1332 with the actual output 9999-12-31 23:59:59.000.

Analysis details: Confidence HIGH | Severity P3 | Testability: THEORETICAL

Found during automated review of PR #109421.

---

ClickGapAI · Confidence: HIGH · Severity: P3 · Finding: h_pr109421_001

[zlareb1]

@groeneai fix

[groeneai]

Confirmed and fixed in #110504.

The saturation example SELECT toDateTime64(1546300800000, 3) returns 9999-12-31 23:59:59.000 (verified against a real server), not the documented value.

Note: there are actually two stale copies of this example in FunctionsConversion_reg.cpp:

• the genuine toDateTime64 doc block showed 2282-12-31 00:00:00.000 (the older legacy max) — corrected in Fix toDateTime64 saturation doc example (9999 not 2282) #110504;
• the toDateTime32 doc block contains a mislabeled copy (showing 2299-12-31 23:59:59.000, the value this issue references) — that whole block is being rewritten separately in Fix toDateTime32 embedded docs example that documented toDateTime64 #110459, so Fix toDateTime64 saturation doc example (9999 not 2282) #110504 leaves it untouched to avoid a conflict.