Fix addDay/subDay calls in ManagesFrequencies #57992
Open
+2
−2
Conversation
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
Remove unnecessary parameter from addDay() and subDay() calls. These Carbon methods don't accept parameters - the parameterized versions are addDays() and subDays().
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
This PR removes the unnecessary parameter previously passed to addDay() and subDay() within the ManagesFrequencies::inTimeInterval() method.
In Carbon, the addDay() and subDay() methods do not accept any parameters—they always shift the date by exactly one day. When a variable increment or decrement is required, the correct methods to use are addDays($n) and subDays($n).
The existing implementation behaved correctly only because Carbon silently ignores extra arguments, but relying on this behavior is technically incorrect and may lead to confusion or unexpected issues in the future.
This PR aligns the code with Carbon’s documented API and ensures clearer, more maintainable date-manipulation logic.
Impact
- No breaking changes: behavior remains identical, as only incorrect arguments were removed.
- Improved code correctness: eliminates reliance on undefined method signatures.
- Increased maintainability: future contributors can rely on consistent and documented API usage.