Repository navigation
fix: preserve microsecond precision in Time differences and selection - #1069
Open
mkantautas wants to merge 2 commits into
Open
mkantautas wants to merge 2 commits into
mkantautas wants to merge 2 commits into
Conversation
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #584.
Time.diff()built both totals from hours, minutes and seconds only, so both operands' microseconds were dropped. For example,Time(12, 0, 0, 500000).diff(Time(12, 0, 1))returned 1 second instead of 0.5.Time - Timeusesdiff()and had the same error. This adds the microseconds to both totals.closest()andfarthest()compareddiff(...).in_seconds(), which truncates to whole seconds. Before this change they could pick the wrong candidate when sub-second parts mattered. For example,Time(12, 0, 0, 900000).closest(Time(12, 0, 1), Time(12, 0, 0))returned12:00:00, which is 0.9 seconds away, instead of12:00:01, which is 0.1 seconds away. With precise differences, truncation would also turn distinct sub-second distances into ties. They now comparetotal_seconds(), in line withDateTime.closest()andDateTime.farthest(), which already compare full-precision distances. Equal distances still return the second candidate.Tests:
tests/time/test_diff.pyandtests/time/test_sub.pycover differences within and across seconds, signed results, the minimum and maximum times, and standard-librarytimeoperands.tests/time/test_comparison.pycoversclosest()andfarthest()with sub-second distances, both candidate orders and standard-librarytimecandidates.diff_for_humans()tests now freeze the clock, matching the equivalentDateTimetests. With microsecond precision, a future comparison against a ticking clock can fall just short of a minute or an hour and show the preceding unit, asDateTimealready does.Validation:
master(e06dace), two of the six new comparison tests fail: the cross-secondclosest()andfarthest()cases (24 passed, 2 failed).tests/time/test_diff.py,tests/time/test_sub.pyandtests/time/test_comparison.pygive 97 passed with the pure-Python backend. With the compiled extension, they also give 97 passed; that run used the extension module from the pendulum 3.3.0 wheel, since this change touches no Rust code.tests/test_main.py::test_instance_with_aware_datetime_any_tzinfo, which expects+02:00and getsEurope/Paris. It fails the same way on unchangedmasterwith the same dependencies.Pull Request Check List