-
Notifications
You must be signed in to change notification settings - Fork 62
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
Fix to configuration loads with %(month[+\-][1-12])s that go out of range #264
Conversation
end_date = datetime.datetime( | ||
start_date.year + years, new_month, start_date.day) | ||
except ValueError: | ||
max_day = calendar.monthrange(start_date.year + years, new_month)[1] |
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.
max_day, _ = calendar...
would be more pythonic (remove the [1]
)
Missing tests! I think this calls for some new unit tests for |
return_value=datetime.datetime(2013, 7, 31)) as now_patch: | ||
self.mcp.config = manager.ConfigManager(temp_dir) | ||
self.mcp._load_config() | ||
now_patch.assert_any_call() |
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.
You could also assert that the action.command is the string you expect.
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.
It's still 'echo %(month-1)s'
after the config is loaded (this test only loads and validates the config, it doesn't apply it), so I'm not sure what doing that in this test would accomplish.
Looks good, just a couple minor things |
Fix to configuration loads with %(month[+\-][1-12])s that go out of range
This is a fix to #249. The core of the issue comes from when something with
%(month[+\-][1-12])s
in its command context tries to be loaded on a day of the current month that isn't in the month targeted by the command context. For example, having%(month-1)s
on the 31st of most months will cause an attempted creation of adatetime
object ofdatetime(year, month, 31)
whenmonth
is something like06
(June, current month is July).This fix simply checks if the day was greater than it should have been, and if so, sets it to whatever the last day of the desired month is/was/will be. If this isn't what caused the exception, we raise it again.
We don't have to worry about not raising an exception in a case where the original starting day was invalid, as day deltas are handled differently (it just is a movement of that exact number of days, regardless of month or year), and this issue only happens in the creation of the second datetime object used for week and month delta calculation (so if the original day was invalid, we'll still get an exception).