{"action":"created","issue":{"url":"https://api.github.com/repos/Scille/umongo/issues/44","repository_url":"https://api.github.com/repos/Scille/umongo","labels_url":"https://api.github.com/repos/Scille/umongo/issues/44/labels{/name}","comments_url":"https://api.github.com/repos/Scille/umongo/issues/44/comments","events_url":"https://api.github.com/repos/Scille/umongo/issues/44/events","html_url":"https://github.com/Scille/umongo/issues/44","id":174333518,"number":44,"title":"DateTime and timezone awareness","user":{"login":"lafrech","id":1767010,"avatar_url":"https://avatars.githubusercontent.com/u/1767010?v=3","gravatar_id":"","url":"https://api.github.com/users/lafrech","html_url":"https://github.com/lafrech","followers_url":"https://api.github.com/users/lafrech/followers","following_url":"https://api.github.com/users/lafrech/following{/other_user}","gists_url":"https://api.github.com/users/lafrech/gists{/gist_id}","starred_url":"https://api.github.com/users/lafrech/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lafrech/subscriptions","organizations_url":"https://api.github.com/users/lafrech/orgs","repos_url":"https://api.github.com/users/lafrech/repos","events_url":"https://api.github.com/users/lafrech/events{/privacy}","received_events_url":"https://api.github.com/users/lafrech/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":10,"created_at":"2016-08-31T17:37:14Z","updated_at":"2016-12-02T20:00:34Z","closed_at":"2016-10-25T07:42:22Z","body":"I'm pulling my hair with datetime TZ awareness issues.\n\nI initiate the connection to MongoDB with `tz_aware = False`. I'm no expert about this, and I had never thought much about it before now, but from what I gathered, it seems like a reasonable choice to make. Besides, it's `pymongo`'s default (but flask-PyMongo's hardcodes `tz_aware` to `True`).\n\nWhen a document is pulled from the DB, its `DateTimeField` attribute's TZ awareness depends only on `MongoClient`'s `tz_aware` parameter (no Marshmallow schema involved):\n\n`tz_aware=True` -> pymongo provides an aware datetime -> umongo returns an aware datetime\n`tz_aware=False` -> pymongo provides a naive datetime -> umongo returns a naive datetime\n\nThis is one more reason to set `tz_aware = False`, because I'm passing a document/object to a lib that expects a naive timezone. (OAuth2 lib expects `expires` timestamp to be naive and compares it to `datetime.utcnow()` ([see code](https://github.com/lepture/flask-oauthlib/blob/e1bb478b2015239dd12f1d3ee13fb2627a5a3407/flask_oauthlib/provider/oauth2.py#L789)).) I suppose I could alternatively modify my getters to make all `datetime`s naive before returning tokens/grants, but on some use cases, it could get cumbersome.\n\nMarshmallow, however, returns every `datetime` as TZ aware ([doc](http://marshmallow.readthedocs.io/en/latest/api_reference.html#marshmallow.fields.DateTime)). For this reason, umongo's `DateTimeField`'s `_deserialize` method returns a TZ aware `datetime`. Since I'm using it (via webargs) to parse the inputs to my API, I'm getting TZ aware `datetime`s. Likewise, calling `load()` on a document will use `_deserialize` and result in a TZ aware `datetime`.\n\nSo if I load a date, it becomes TZ aware. Therefore, to compare it to a date from the database, this one needs to be aware as well.\n\nShould I understand that umongo is meant to be used with `tz_aware=True`, so that dates fetched from the database can be compared to dates loaded thought Marshmallow schemas?\n\nCould there be a flag/meta allowing to specify if a `DateTimeField` should return a naive `datetime`?\n\nI made a quick and dirty patch to `DateTime`'s `_deserialize` to remove the TZ from the returned output.\n\n``` py\n    dt = super()._deserialize(value, attr, data)\n    return dt.replace(tzinfo=None)\n```\n\nThis seems to work on my use case. However, the day we complete pure Marshmallow schema export, the exported schema I pass to webargs for API input parsing won't have that feature. Unless this is added to Marshmallow as well. (I asked there about it there: https://github.com/marshmallow-code/marshmallow/issues/520.)\n\nFeedback welcome. Those TZ issues are new to me, so I may be totally misguided.\n"},"comment":{"url":"https://api.github.com/repos/Scille/umongo/issues/comments/264548526","html_url":"https://github.com/Scille/umongo/issues/44#issuecomment-264548526","issue_url":"https://api.github.com/repos/Scille/umongo/issues/44","id":264548526,"user":{"login":"lafrech","id":1767010,"avatar_url":"https://avatars.githubusercontent.com/u/1767010?v=3","gravatar_id":"","url":"https://api.github.com/users/lafrech","html_url":"https://github.com/lafrech","followers_url":"https://api.github.com/users/lafrech/followers","following_url":"https://api.github.com/users/lafrech/following{/other_user}","gists_url":"https://api.github.com/users/lafrech/gists{/gist_id}","starred_url":"https://api.github.com/users/lafrech/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lafrech/subscriptions","organizations_url":"https://api.github.com/users/lafrech/orgs","repos_url":"https://api.github.com/users/lafrech/repos","events_url":"https://api.github.com/users/lafrech/events{/privacy}","received_events_url":"https://api.github.com/users/lafrech/received_events","type":"User","site_admin":false},"created_at":"2016-12-02T20:00:34Z","updated_at":"2016-12-02T20:00:34Z","body":"Thanks @nedwill for pointing this.\r\n\r\nBTW, I just found out a surprising behaviour of `DateTime` field in Marshmallow that also affects `StrictDateTimeField`. See https://github.com/marshmallow-code/marshmallow/issues/556\r\n\r\n```py\r\nf = fields.DateTime()\r\nf.deserialize('1916')\r\n# datetime.datetime(1916, 11, 30, 0, 0)\r\nf.deserialize('1916-2')\r\n# datetime.datetime(1916, 2, 29, 0, 0)\r\nf.deserialize('1916-3')\r\n# datetime.datetime(1916, 3, 30, 0, 0)\r\n```\r\n\r\nThose inputs should be rejected or default to something more predictable.\r\n\r\nIt is not _that_ bad. It won't break the application. But until it's fixed upstream, it's good to know."}}
{"actor":{"display_login":"lafrech"}}