fix: Don't silently produce null values from invalid input to pl.datetime and pl.date

[mcrumiller]

Fixes #20977.

I am not sure if this is a breaking change or not.

Example of new behavior:

>>> import polars as pl
>>> pl.select(pl.date(2025, 13, 1))  # month 13 is invalid (pl.Date)
polars.exceptions.ComputeError: Invalid date components (2025, 13, 1) supplied

>>> pl.select(pl.datetime(2025, 13, 1))  # month 13 is invalid (pl.Datetime)
polars.exceptions.ComputeError: Invalid date components (2025, 13, 1) supplied


>>> pl.select(pl.datetime(2025, 1, 1, 25))  # hour 25 is invalid
polars.exceptions.ComputeError: Invalid time components (25, 0, 0, 0) supplied

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 79.96%. Comparing base (3719977) to head (78e4281).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #21013      +/-   ##
==========================================
+ Coverage   79.89%   79.96%   +0.06%     
==========================================
  Files        1597     1597              
  Lines      228951   228964      +13     
  Branches     2618     2618              
==========================================
+ Hits       182915   183080     +165     
+ Misses      45437    45285     -152     
  Partials      599      599              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ritchie46]

We really should return an error here, not a panic.

[mcrumiller]

@ritchie46 I wasn't quite sure how to go about this, so let me know if it needs rework. Right now, we have an iterator that yields Option<i32>s that are collected by the trusted len iterator. I could have returned Result<Option<i32>> for each item and updated the trusted len iterator to collect this into a Result<Int32Chunked> but this would require messing with the legacy module in polars-arrow which I didn't really want to do, since FromTrustedLenIterator doesn't collect Results.

Instead, I opted to flag if an invalid value is observed during the array creation, and proceed as we used to (filling with nulls). Then I check in hindsight if an invalid value was observed, and at that point throw a ComputeError. The downside is that the iterator doesn't halt immediately, but since the operation is failing anyway this doesn't seem that awful to me. Let me know if this sounds reasonable, and if not I can try to rework it some more.

[ritchie46]

You can return a result and then call try_collect_ca_with_dtype, that's a bit cleaner.