-
-
Notifications
You must be signed in to change notification settings - Fork 18.5k
BUG: Timedelta drops decimals if precision is greater than nanoseconds #36771
New issue
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
Conversation
/azp run |
Commenter does not have sufficient privileges for PR 36771 in repo pandas-dev/pandas |
Failure seems weird, maybe rerunning the pipeline? |
I think truncation is reasonable. I think it would be good to document this behavior in Could you also add a test that goes through |
� Conflicts: � doc/source/whatsnew/v1.2.0.rst
The test ran through |
Failure unrelated |
� Conflicts: � doc/source/whatsnew/v1.2.0.rst
This pull request is stale because it has been open for thirty days with no activity. Please update or respond to this comment if you're still interested in working on this. |
Mind merge master @phofl? This LGTM after that |
@mroeschke done |
ci failure is from master and will be fixed with #37756 |
@phofl I merged that PR, so you can update here as well now |
Thanks, done |
pandas/core/tools/timedeltas.py
Outdated
@@ -66,6 +66,12 @@ def to_timedelta(arg, unit=None, errors="raise"): | |||
to_datetime : Convert argument to datetime. | |||
convert_dtypes : Convert dtypes. | |||
|
|||
Notes | |||
----- | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no extra line here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thx, changed
("8:53:08.7180000001", "8:53:08.7180000001"), | ||
], | ||
) | ||
@pytest.mark.parametrize("func", ["Timedelta", "to_timedelta"]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use pd.Timedelta and pd.to_datetime instead of passing these as strings and using getattr below
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
doc/source/whatsnew/v1.2.0.rst
Outdated
@@ -404,6 +404,7 @@ Datetimelike | |||
- Bug in :meth:`DatetimeArray.shift` incorrectly allowing ``fill_value`` with a mismatched timezone (:issue:`37299`) | |||
- Bug in adding a :class:`BusinessDay` with nonzero ``offset`` to a non-scalar other (:issue:`37457`) | |||
- Bug in :func:`to_datetime` with a read-only array incorrectly raising (:issue:`34857`) | |||
- Bug in :class:`Timedelta` incorrectly deleted all decimals when input had a higher precision than nanoseconds (:issue:`36738`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"incorrectly truncating to sub-second portion of a string input when it has precision higher than nanoseconds"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
@@ -1143,6 +1145,9 @@ class Timedelta(_Timedelta): | |||
Notes | |||
----- | |||
The ``.value`` attribute is always in ns. | |||
|
|||
If the precision is higher than nanoseconds, the precision of the duration is | |||
truncated to nanoseconds. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clarify this is for a string input
do additional digits round or just drop (and if just drop, are we sure thats the desired behavior?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dropd additional digits. Was not sure either so I started with the easier implementation
#36771 (comment)
@pytest.mark.parametrize( | ||
("input", "expected"), | ||
[ | ||
("8:53:08.71800000001", "8:53:08.718"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you add a case with the trailing digit being 9 to clarify the truncating/rounding distinction
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
# GH: 36738 | ||
expected = pd.Timedelta(expected) | ||
result = func(input) | ||
print(result) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove the print
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry forgot that, is removed
doc/source/whatsnew/v1.2.0.rst
Outdated
@@ -404,6 +404,7 @@ Datetimelike | |||
- Bug in :meth:`DatetimeArray.shift` incorrectly allowing ``fill_value`` with a mismatched timezone (:issue:`37299`) | |||
- Bug in adding a :class:`BusinessDay` with nonzero ``offset`` to a non-scalar other (:issue:`37457`) | |||
- Bug in :func:`to_datetime` with a read-only array incorrectly raising (:issue:`34857`) | |||
- Bug in :class:`Timedelta` incorrectly truncating to sub-second portion of a string input when it has precision higher than nanoseconds (:issue:`36738`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you move to section below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
thanks @phofl |
black pandas
git diff upstream/master -u -- "*.py" | flake8 --diff
I am not quite sure, if we should round to nanoseconds or cut if off after the 9th decimal. I implemented a simple cut off, but would be happy to change if rounding is better.
I would also add a note to the user guide if the future behavior is clear