Open stinodego opened 9 months ago
I think this is just the usual chrono limitation of 262,000 +/- unix epoch
use chrono; // 0.4.31
fn main() {
let res = chrono::NaiveDateTime::from_timestamp_opt(8200000000000, 0);
println!("res: {:?}", res); // res: Some(+261817-08-28T09:46:40)
let res = chrono::NaiveDateTime::from_timestamp_opt(8300000000000, 0);
println!("res: {:?}", res); // res: None
}
Right, that makes sense. What about the nanosecond underflow, though? Should it not also raise invalid or out-of-range datetime
?
Also, I think it would be good to add those limits to the docstring of the Datetime class (and perhaps Date/Time/Duration if those have similar limitations).
will check about the nanosec one
agree on documenting this limit
Checks
[X] I have checked that this issue has not already been reported.
[X] I have confirmed this bug exists on the latest version of Polars.
Reproducible example
Investigating further, it's not just printing that fails, but further computation with the column also fails:
The limit seems to be somewhere around
8_334_000_000_000_000_000
for microsecond datetimes:For nanosecond, it seems to underflow:
Log output
For the print:
Issue description
Casting min/max i64 values to datetime works, but subsequent computation fails.
Expected behavior
The datetime value should be printed normally.
Installed versions
main branch