fix: DateTimeParts cast failures

[a10y]

Rationale for this change

We had a latent bug here where if you had a DTP that narrowed from i64 -> something smaller, and then you had a larger i64 come along as a constant to compare against, that compare would fail and the failure would propagate to the caller.

What changes are included in this PR?

Instead of letting the cast fail lazily at execution time, we cast the constant upfront, and if it fails we handle it.

If the value is large positive i64, then we can assume > all of lhs

If the value is large negative i64, then we can assume < all of lhs

What APIs are changed? Are there any user-facing changes?

None

[codspeed-hq]

Merging this PR will degrade performance by 1.51%

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

⚡ 1 improved benchmark
❌ 1 regressed benchmark
✅ 1992 untouched benchmarks
⏩ 89 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	WallTime	words_gather_scalar[65536]	8.3 µs	9.4 µs	-11.82%
⚡	WallTime	words_gather_dispatch[1024]	33 ns	30 ns	+10%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing aduffy/fix-dtp-cast (5e8d836) with develop (1a493b6)}

Footnotes

1. 89 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[joseph-isaacs]

are you sure about boundary conditions with => and others?

also it is always signed or do we allow signed and unsigned values?

[a10y]

are you sure about boundary conditions with => and others?

Hmm you mean because of nulls?

also it is always signed or do we allow signed and unsigned values?

This particular codepath we always receive i64, and those can be negative if e.g. timestamp is before epoch

[a10y]

Ok I pushed a fix for nulls handling