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.
In the below example, notice how the microseconds in the result match for the tz-naive case, but not for the tz-aware one
In [62]: pl.Series([datetime(2514, 5, 30, 1, 53, 4, 986754)]) Out[62]: shape: (1,) Series: '' [datetime[μs]] [ 2514-05-30 01:53:04.986754 ] In [63]: pl.Series([datetime(2514, 5, 30, 1, 53, 4, 986754, tzinfo=dt.timezone.utc)]) Out[63]: shape: (1,) Series: '' [datetime[μs, UTC]] [ 2514-05-30 01:53:04.986756 UTC ]
In the second case
In [63]: pl.Series([datetime(2514, 5, 30, 1, 53, 4, 986754, tzinfo=dt.timezone.utc)]) Out[63]: shape: (1,) Series: '' [datetime[μs, UTC]] [ 2514-05-30 01:53:04.986754 UTC ]
The issue is that in the tz-aware case,
polars/py-polars/polars/internals/construction.py
Lines 329 to 332 in 8d5585d
PySeries.new_from_anyvalues is used.
PySeries.new_from_anyvalues
And in that one, in
polars/py-polars/src/series.rs
Lines 227 to 232 in 9cfc987
avs will already have incorrectly converted to int:
avs
int
[Datetime(17179869184986756, Microseconds, None)]
But that number is incorrect:
In [7]: dt.datetime(1970, 1, 1, tzinfo=dt.timezone.utc) + dt.timedelta(microseconds=17179869184986756) Out[7]: datetime.datetime(2514, 5, 30, 1, 53, 4, 986756, tzinfo=datetime.timezone.utc)
It should be 17179869184986754:
17179869184986754
In [8]: dt.datetime(1970, 1, 1, tzinfo=dt.timezone.utc) + dt.timedelta(microseconds=17179869184986754) Out[8]: datetime.datetime(2514, 5, 30, 1, 53, 4, 986754, tzinfo=datetime.timezone.utc)
---Version info--- Polars: 0.16.6 Index type: UInt32 Platform: Linux-5.10.102.1-microsoft-standard-WSL2-x86_64-with-glibc2.35 Python: 3.11.1 (main, Dec 7 2022, 01:11:34) [GCC 11.3.0] ---Optional dependencies--- pyarrow: 11.0.0 pandas: 1.5.3 numpy: 1.24.1 fsspec: <not installed> connectorx: <not installed> xlsx2csv: <not installed> deltalake: <not installed> matplotlib: <not installed>
The text was updated successfully, but these errors were encountered:
Just to link it here, perhaps somewhat related or same code branches: #7212
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
In the below example, notice how the microseconds in the result match for the tz-naive case, but not for the tz-aware one
Reproducible example
Expected behavior
In the second case
The issue is that in the tz-aware case,
polars/py-polars/polars/internals/construction.py
Lines 329 to 332 in 8d5585d
PySeries.new_from_anyvalues
is used.And in that one, in
polars/py-polars/src/series.rs
Lines 227 to 232 in 9cfc987
avs
will already have incorrectly converted toint
:But that number is incorrect:
It should be
17179869184986754
:Installed versions
The text was updated successfully, but these errors were encountered: