-
Notifications
You must be signed in to change notification settings - Fork 152
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
Duration.compare() #1163
Duration.compare() #1163
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1163 +/- ##
==========================================
- Coverage 93.55% 90.75% -2.81%
==========================================
Files 19 17 -2
Lines 7961 8913 +952
Branches 1264 1260 -4
==========================================
+ Hits 7448 8089 +641
- Misses 506 811 +305
- Partials 7 13 +6
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
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.
Looks good, other than not adjusting for DST which I assume will be in a later PR.
ad6ef47
to
4346e12
Compare
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.
Overall this looks fine, except I didn't understand why there's code to accommodate ZDT and DST changes but no tests that cover the case where a DST change is inside the duration. Is that case expected to work after this PR, and if so then why no tests?
Sorry for the confusion about this — those cases are not yet expected to work after this PR, so that's why I didn't add those tests. Only compare() has a relativeTo that actually works as expected with ZonedDateTime. The other methods (round(), total(), add(), subtract()) accept ZonedDateTime after this PR, but still always treat days as 24 hours. I am working on (hopefully only) one more followup PR that should make the rest of these work with DST shifts. |
4346e12
to
9262141
Compare
<emu-alg> | ||
1. If _days_ ≠ 0, then | ||
1. Set _nanoseconds_ to ℝ(_nanoseconds_) − ℝ(_offsetShift_). |
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.
Followup: this is not great - nanoseconds ends up being a JS Number or a Mathematical Value depending on the value of days. Let's convert it unconditionally before the days check.
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.
Will address this in the next PR, thanks.
This operation gives the total number of nanoseconds in an exact duration as a bigint, not losing precision. This will be reused in Duration.compare(). This operation takes an "offset shift" parameter, used if there are days that need to be balanced down to hours. If it's 0 (as is the case everywhere in this commit) then days are always 24 hours. We will start using nonzero values for this in Duration.compare(). See: #856
Everywhere a relativeTo option is accepted, allow a ZonedDateTime instance or a value that is convertible to one. If converting a value, preferentially convert to ZonedDateTime if there is enough information (i.e. the time zone name is present), only if not then convert to PlainDateTime.
Implements a Duration.compare() static method with a relativeTo option for comparing durations with date units. See: #856
9262141
to
6c877a8
Compare
Closes: #856