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.27%. Comparing base (98ccb09) to head (1cdac2c).

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #21013      +/-   ##
==========================================
+ Coverage   79.21%   79.27%   +0.06%     
==========================================
  Files        1583     1583              
  Lines      225545   225584      +39     
  Branches     2586     2586              
==========================================
+ Hits       178664   178842     +178     
+ Misses      46291    46152     -139     
  Partials      590      590              

☔ 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.