#21432 closed Bug (fixed)
datetimes method always raise AttributeError
Reported by: | Owned by: | Aymeric Augustin | |
---|---|---|---|
Component: | Core (Other) | Version: | 1.6 |
Severity: | Release blocker | Keywords: | |
Cc: | Tim Graham, Baptiste Mispelon, loic@… | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
NewsItem.objects.all().datetimes('date_time', 'month', order='DESC') always raises: AttributeError: 'DateTimeQuery' object has no attribute 'tzinfo'
and it happens with all my models with some DateTimeField.
Attachments (1)
Change History (14)
comment:1 by , 11 years ago
Cc: | added |
---|---|
Component: | Uncategorized → Core (Other) |
Severity: | Normal → Release blocker |
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 11 years ago
>>> Poll.objects.datetimes('pub_date', 'month') Traceback (most recent call last): File "<console>", line 1, in <module> File "/home/timgraham/code/django/django/db/models/query.py", line 115, in __repr__ data = list(self[:REPR_OUTPUT_SIZE + 1]) File "/home/timgraham/code/django/django/db/models/query.py", line 140, in __iter__ self._fetch_all() File "/home/timgraham/code/django/django/db/models/query.py", line 962, in _fetch_all self._result_cache = list(self.iterator()) File "/home/timgraham/code/django/django/db/models/sql/compiler.py", line 1089, in results_iter datetime = timezone.make_aware(datetime, self.query.tzinfo) AttributeError: 'DateTimeQuery' object has no attribute 'tzinfo'
comment:3 by , 11 years ago
Bisecting the error lead me to commit 70679243d1786e03557c28929f9762a119e3ac14, but it's not really obvious (to me anyway) why that would have broken the feature.
follow-up: 5 comment:4 by , 11 years ago
It is possible the above commit just makes the error loud instead of hiding the error and returning silently []. Before the commit errors inside queryset iteration led to empty list as result.
comment:5 by , 11 years ago
Cc: | added |
---|
Replying to akaariai:
It is possible the above commit just makes the error loud instead of hiding the error and returning silently []. Before the commit errors inside queryset iteration led to empty list as result.
Indeed, this appears to be the case.
While digging, I also found out that the following code works:
qs = Poll.objects.datetimes('pub_date', 'month') list(qs) repr(qs)
While this one doesn't (note how repr
and list
have been switched):
qs = Poll.objects.datetimes('pub_date', 'month') repr(qs) list(qs)
This explains why this issue has been able to fall through the cracks: iterating over a queryset is a much more common use-case than displaying it as-is.
Unfortunately, I haven't been able to identify exactly where the problem lies (I have a suspicion that it's got something to do with the _clone
method though) but I've managed to come up with a failing testcase (see attached).
comment:6 by , 11 years ago
Yeah, the problem seem to be that when doing qs.datetimes() the DateTimeQuery gets a tzinfo attribute (datetimes() end up in here: https://github.com/django/django/blob/master/django/db/models/query.py#L1255), but if the query gets cloned afterwards the tzinfo attribute will not get cloned. The solution seems to be to write a custom .clone() for DateTimeQuery.
comment:7 by , 11 years ago
Cc: | added |
---|---|
Has patch: | set |
comment:8 by , 11 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
The patch looks appropriate.
The test could be simplified a bit with now = timezone.now().replace(microsecond=0)
.
comment:9 by , 11 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
Patch looks good.
It fixes the issue and the full test suite still passes after applying it.
comment:10 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I can reproduce this on the tutorial with the following query:
Poll.objects.datetimes('pub_date', 'month')
(Python 2.7, pytz 2013.8, settings.USE_TZ=True). Tentatively marking as a release blocker as I don't see anything wrong with that based on the documentation. On the other hand, we have tests that seem to test the same thing, so wihout digging in I'm unsure what the issue might be.