We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I have checked that this issue has not already been reported.
I have confirmed this bug exists on the latest version of Polars.
When trying to reproduce https://pola-rs.github.io/polars-book/user-guide/expressions/casting/#dates in a library that uses Polars, I ran across surprising behavior where date_range will return surprising results.
date_range
https://github.com/mt-caret/polars-ocaml/blob/9fa0eb6c59034413ce679b63068d7f9db2bbc0f9/rust/src/lib.rs:
#[cfg(test)] mod tests { use chrono::naive::NaiveDate; use expect_test::{expect, Expect}; use polars::prelude::prelude::*; use polars::prelude::*; use std::fmt::Debug; fn check<T: Debug>(actual: T, expect: Expect) { let actual = format!("{:?}", actual); expect.assert_eq(&actual); } #[test] fn check_date_range() { let start = NaiveDate::from_ymd_opt(2022, 1, 1) .unwrap() .and_hms_opt(0, 0, 0) .unwrap(); let stop = NaiveDate::from_ymd_opt(2022, 1, 5) .unwrap() .and_hms_opt(0, 0, 0) .unwrap(); check( date_range( "date", start, stop, Duration::parse("1d"), ClosedWindow::Both, TimeUnit::Nanoseconds, None, ) .map(|date_range| date_range.into_series()), expect![[r#" Ok(shape: (5,) Series: 'date' [datetime[ns]] [ 2022-01-01 00:00:00 2022-01-02 00:00:00 2022-01-03 00:00:00 2022-01-04 00:00:00 2022-01-05 00:00:00 ])"#]], ); check( date_range( "date", start, stop, Duration::parse("1d"), ClosedWindow::Both, TimeUnit::Microseconds, // TODO: BUG! None, ) .map(|date_range| date_range.into_series()), expect![[r#" Ok(shape: (1,) Series: 'date' [datetime[μs]] [ 1970-01-01 00:27:20.995200 ])"#]], ); check( date_range( "date", start, stop, Duration::parse("1d"), ClosedWindow::Both, TimeUnit::Milliseconds, None, ) .map(|date_range| date_range.into_series()), expect![[r#" Ok(shape: (5,) Series: 'date' [datetime[ms]] [ 2022-01-01 00:00:00 2022-01-02 00:00:00 2022-01-03 00:00:00 2022-01-04 00:00:00 2022-01-05 00:00:00 ])"#]], ) } }
date_range to produce the same result regardless of the time unit specified for this particular case.
[ "lazy", "dot_diagram", "parquet", "approx_unique", "dtype-date", "dtype-datetime", "dtype-i8", "dtype-i16", "dtype-u8", "dtype-u16", "random", "describe", "streaming" ]
The text was updated successfully, but these errors were encountered:
thanks @mt-caret for the report! fix incoming
Sorry, something went wrong.
Successfully merging a pull request may close this issue.
Polars version checks
I have checked that this issue has not already been reported.
I have confirmed this bug exists on the latest version of Polars.
Issue description
When trying to reproduce https://pola-rs.github.io/polars-book/user-guide/expressions/casting/#dates in a library that uses Polars, I ran across surprising behavior where
date_range
will return surprising results.Reproducible example
https://github.com/mt-caret/polars-ocaml/blob/9fa0eb6c59034413ce679b63068d7f9db2bbc0f9/rust/src/lib.rs:
Expected behavior
date_range
to produce the same result regardless of the time unit specified for this particular case.Installed versions
[ "lazy", "dot_diagram", "parquet", "approx_unique", "dtype-date", "dtype-datetime", "dtype-i8", "dtype-i16", "dtype-u8", "dtype-u16", "random", "describe", "streaming" ]
The text was updated successfully, but these errors were encountered: