-
Notifications
You must be signed in to change notification settings - Fork 533
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
(overflowing|checked)_(add|sub)_offset
implementations
#1069
Conversation
4ac7509
to
114fec8
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.
Approve with docstring nitpicks
114fec8
to
1f7645a
Compare
It seems like I have to rebase stuff after every merged PR to fix merge conflicts. A few more weeks like this and no one can beat me at rebasing 😆. |
1f7645a
to
d20c780
Compare
@djc I believe you were halfway done with reviewing this PR in #1071 (comment)? Three other PRs depend on this one. Not meant to hurry you. Just wanting to highlight this is a good first one of my open PRs. |
Yup, this is on my list (perhaps counterintuitively, the lack of a waiting-on-review label means I expect to review this sooner rather than the ones labeled as such -- if you have a suggestion for a better label name, I'm all ears). |
d20c780
to
f54d7a8
Compare
f54d7a8
to
37e6a98
Compare
37e6a98
to
ce58270
Compare
ce58270
to
5911afc
Compare
90c8384
to
6e00637
Compare
@djc this PR is now quite small and the new |
6e00637
to
85a1ebc
Compare
Codecov Report
@@ Coverage Diff @@
## 0.4.x #1069 +/- ##
==========================================
+ Coverage 91.21% 91.25% +0.03%
==========================================
Files 38 38
Lines 17121 17114 -7
==========================================
Hits 15617 15617
+ Misses 1504 1497 -7
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
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.
Old review comment that's been stuck in pending mode...
src/naive/time/mod.rs
Outdated
/// added to a date as a result of the offset (either `-1`, `0`, or `1` because the offset is | ||
/// always less than 24h). | ||
/// | ||
/// This method is similar to [`overflowing_add_signed`], but preserves leap seconds. |
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 we replace the implementation of overflowing_add_signed()
to use this instead to be more correct?
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.
overflowing_add_signed()
is not incorrect, or at least it works with leap seconds as documented.
Adding one hour to 13:59:60 with overflowing_add_signed
should result in 14:59:59 (3600 seconds later).
But when adding a FixedOffset
to convert a value from one time zone to another, it should do nothing special with leap seconds.
Adding one hour to 13:59:60 with overflowing_add_offset
should result in 14:59:60 (the same value, but shifted by 3600 seconds).
0910523
to
e74dcba
Compare
I'm aware, but you keep submitting other stuff... |
Haha, yes, that is my fault. But if we want to take some time with little new work to get the existing PRs ready that is fine with me. |
e74dcba
to
8c53477
Compare
Added a small optimization to Before the
After the
Now:
In total we are ca. 35% faster in a good number of methods on |
Let's split this in 3 parts? |
8c53477
to
23d9c3e
Compare
23d9c3e
to
018be06
Compare
This PR now contains only a tiny part 4. |
@@ -1247,6 +1247,16 @@ impl<Tz: TimeZone> AddAssign<Duration> for DateTime<Tz> { | |||
} | |||
} | |||
|
|||
impl<Tz: TimeZone> Add<FixedOffset> for DateTime<Tz> { |
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.
In my opinion this impl doesn't make much sense. Should the offset be added to the datetime, or to the offset? And why? I would like to remove it on main.
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.
Removing it on main sounds good to me.
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.
I'll make a PR soon-ish.
@@ -1247,6 +1247,16 @@ impl<Tz: TimeZone> AddAssign<Duration> for DateTime<Tz> { | |||
} | |||
} | |||
|
|||
impl<Tz: TimeZone> Add<FixedOffset> for DateTime<Tz> { |
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.
Removing it on main sounds good to me.
Split out from #1048.
The main goal is to add
NaiveDateTime::checked_(add|sub)_offset
methods. To quote from #1048:Instead of panicking in the
Add
orSub
implementation ofNaiveDateTime
withFixedOffset
, we need a way to be informed of out-of-range result.I added the following methods
(not public for now):NaiveTime::overflowing_add_offset
andNaiveTime::overflowing_sub_offset
NaiveDateTime::checked_add_offset
andNaiveDateTime::checked_sub_offset
The
Add
andSub
implementations ofFixedOffset
withNaiveTime
,NaiveDateTime
andDateTime
are reimplemented using of these methods. This fixes a code comment:The best place to put the
Add
andSub
implementations forDateTime
is in the module ofDateTime
, because there they have access to its private fields. I have moved all implementations to the module of their output type for consistency.Adding an offset works differently from adding a duration. Adding a duration tries to do something smart—but still rudimentary—with leap seconds. Adding an offset should not touch the leap seconds at all. So the methods that operate on
NaiveTime
should be different.I extracted the part that operates on the
NaiveDate
that could be shared into anadd_days
methods. PreviouslyNaiveDate::checked_add_days
would convert the days to aDuration
in seconds, and later devide them to get the value in days again. This now works in a less roundabout way.MightThis would also help with the const implementation later.