aboutsummaryrefslogtreecommitdiffstats
path: root/tests/test_converters.py (follow)
Commit message (Collapse)AuthorAgeLines
* Check if tzinfo is None in ISODateTime testGravatar Sebastiaan Zeeff2019-10-03-1/+3
| | | | | | | As we have decided that the converter should return naive datetime objects, we should explicitly test that datetime strings with a timezone offset are still converted to a naive datetime object. I have done this by adding a `tzinfo is None` assertion.
* Make ISODateTime return tz-unaware datetimeGravatar Sebastiaan Zeeff2019-10-02-0/+21
| | | | | | | | | | | | | | | | | | | | | The parser we use, `dateutil.parsers.isoparse` returns a timezone- aware or timezone-unaware `datetime` object depending on whether or not the datetime string included a timezone offset specification. Since we can't compare tz-aware objects to tz-unaware objects it's better to make sure our converter is consistent in the type it will return. For now, I've chosen to return tz-unaware datetime objects, since `discord.py` also returns tz-unaware datetime objects when accessing datetime-related attributes of objects. Since we're likely to compare "our" datetime objects to discord.py-provided datetime objects, I think that's the most parsimonious option for now. Note: It's probably a good idea to open a larger discussion about using timezone-aware datetime objects throughout the library to avoid a UTC-time being interpreted as localtime. This will require a broader discussion than this commit/PR allows, though.
* Apply docstring review suggestionGravatar Sebastiaan Zeeff2019-10-02-1/+1
| | | Co-Authored-By: Mark <[email protected]>
* Add converter for ISO-formatted datetime stringsGravatar Sebastiaan Zeeff2019-10-01-0/+55
| | | | | | | | | | | | | | | Related to https://github.com/python-discord/bot/issues/458 This commit adds a converter that automatically parses ISO-formatted datetime strings and returns a `datetime.datetime` object. It uses `dateutil.parser.isoparse` to do the heavy lifting, so it supports the same formats as this method. In addition, I have added tests that ensure that it accepts certain formats and added a description of these 'guaranteed' formats to the `ISODate.convert` docstring. This commit should make it easy to implement #485
* Allow whitespace in duration strings and update testsGravatar Sebastiaan Zeeff2019-09-23-47/+66
| | | | | | | | | | | | | | | | | | | | | https://github.com/python-discord/bot/issues/446 After review feedback and a discussion in the dev-core team, I've changed a couple of things: - Allow a space between amount and unit in the duration string; - Allow a space between different units in the duration string; - Remove the old ExpirationDate converter completely; - Remove the dependency `dateparser` from the Pipfile; - Update tests for the two types of optional spaces; - Change the test for valid cases to a more readable format; This PR closes #446
* Fix failing duration conversionGravatar Sebastiaan Zeeff2019-09-23-4/+78
| | | | | | | | | | | | | | | | | | | https://github.com/python-discord/bot/issues/446 The current ExpirationDate converter does not convert duration strings to `datetime.datetime` objects correctly. To remedy the problem, I've written a new Duration converter that uses regex matching to extract the relevant duration units and `dateutil.relativedelta.relativedelta` to compute a `datetime.datetime` that's the given duration in the future. I've left the old `ExpirationDate` converter in place for now, since the new Duration converter may not be the most optimal method. However, given the importance of being able to convert durations for moderation tasks, I think it's better to implement Duration now and rethink the approach later. This commit closes #446
* Add tests for `bot.converters`.Gravatar Johannes Christ2019-09-15-0/+93