Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Add converter for ISO-formatted datetime strings #473
This pull requests adds a converter that automatically parses ISO-formatted datetime strings and returns a
In addition, I've added tests that "guarantee" that certain standard formats will be accepted and added these "guaranteed" formats to the docstring of the
This pull request should make it easy to implement #458. However, I did not yet want to touch the moderation cog, since it's currently being worked on by @MarkKoz. If we merge this soon, Mark may be able to directly implement it during the work he's doing anyway, though.
Related to #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
MarkKoz left a comment
How should time zones be dealt with? There is some other code that expects timezone-naïve datetimes (for example,
This converter does not force
>>> dateutil.parser.isoparse("2019-09-01T10:10:10") datetime.datetime(2019, 9, 1, 10, 10, 10) >>> dateutil.parser.isoparse("2019-09-01T10:10:10Z") datetime.datetime(2019, 9, 1, 10, 10, 10, tzinfo=tzutc())
Do you think we should restrict this to one or the other at the level of the converter?
Yeah, I was aware it depends on the input. Inputs that result in timezone-aware datetimes could be problematic.
Well, maybe. But as I said, perhaps a more proper solution would be to make other things work with timezone-aware datetimes. It'd be nice to support timezones in user inputs but right now it isn't an important feature anywhere (but could be in the future).
I don't know how feasible it is to support timezone-aware datetimes everywhere. Our API already returns a
Okay, I've looked into the option of using timezone-aware
The reason is that
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.
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.