{{{
2014-10-26 02:40:14,104 ERROR django.request
:handle_uncaught_exception 231 Internal Server Error:
/dashboard/suppliers/
Traceback (most recent call last):
File "/home/markus/src/django/django/core/handlers/base.py", line 111,
in get_response
response = wrapped_callback(request, *callback_args,
**callback_kwargs)
File "/home/markus/src/django/django/db/transaction.py", line 394, in
inner
return func(*args, **kwargs)
File "/home/markus/src/django/django/contrib/auth/decorators.py", line
22, in _wrapped_view
return view_func(request, *args, **kwargs)
File "/home/markus/src/django/django/contrib/auth/decorators.py", line
22, in _wrapped_view
return view_func(request, *args, **kwargs)
File "/home/markus/src/django/django/views/generic/base.py", line 69, in
view
return self.dispatch(request, *args, **kwargs)
File "/home/markus/src/django/django/views/generic/base.py", line 87, in
dispatch
return handler(request, *args, **kwargs)
File "/home/markus/src/django/django/views/generic/list.py", line 145,
in get
self.object_list = self.get_queryset()
File "/home/markus/src/machtfit/apps/dashboard/supplier/views.py", line
44, in get_queryset
.annotate(num_orders=Count('partner__order_line')))
File "/home/markus/src/django/django/db/models/query.py", line 802, in
annotate
is_summary=False)
File "/home/markus/src/django/django/db/models/sql/query.py", line 1012,
in add_aggregate
field_list, opts, self.get_initial_alias())
File "/home/markus/src/django/django/db/models/sql/query.py", line 1419,
in setup_joins
names, opts, allow_many, fail_on_missing=True)
File "/home/markus/src/django/django/db/models/sql/query.py", line 1383,
in names_to_path
self.raise_field_error(opts, name)
File "/home/markus/src/django/django/db/models/sql/query.py", line 1389,
in raise_field_error
"Choices are: %s" % (name, ", ".join(available)))
FieldError: Cannot resolve keyword u'order_line' into field. Choices are:
<irrelevant>
Traceback (most recent call last):
File "/usr/lib/python2.7/wsgiref/handlers.py", line 85, in run
self.result = application(self.environ, self.start_response)
File "/home/markus/src/django/django/contrib/staticfiles/handlers.py",
line 64, in __call__
return self.application(environ, start_response)
File "/home/markus/src/django/django/core/handlers/wsgi.py", line 187,
in __call__
response = self.get_response(request)
File "/home/markus/src/django/django/core/handlers/base.py", line 199,
in get_response
response = self.handle_uncaught_exception(request, resolver,
sys.exc_info())
File "/home/markus/src/django/django/core/handlers/base.py", line 236,
in handle_uncaught_exception
return debug.technical_500_response(request, *exc_info)
File "/home/markus/src/django/django/views/debug.py", line 91, in
technical_500_response
html = reporter.get_traceback_html()
File "/home/markus/src/django/django/views/debug.py", line 350, in
get_traceback_html
return t.render(c)
File "/home/markus/src/django/django/template/base.py", line 148, in
render
return self._render(context)
File "/home/markus/src/django/django/test/utils.py", line 88, in
instrumented_test_render
return self.nodelist.render(context)
File "/home/markus/src/django/django/template/base.py", line 844, in
render
bit = self.render_node(node, context)
File "/home/markus/src/django/django/template/debug.py", line 80, in
render_node
return node.render(context)
File "/home/markus/src/django/django/template/debug.py", line 90, in
render
output = self.filter_expression.resolve(context)
File "/home/markus/src/django/django/template/base.py", line 624, in
resolve
new_obj = func(obj, *arg_vals)
File "/home/markus/src/django/django/template/defaultfilters.py", line
769, in date
return format(value, arg)
File "/home/markus/src/django/django/utils/dateformat.py", line 343, in
format
return df.format(format_string)
File "/home/markus/src/django/django/utils/dateformat.py", line 35, in
format
pieces.append(force_text(getattr(self, piece)()))
File "/home/markus/src/django/django/utils/dateformat.py", line 268, in
r
return self.format('D, j M Y H:i:s O')
File "/home/markus/src/django/django/utils/dateformat.py", line 35, in
format
pieces.append(force_text(getattr(self, piece)()))
File "/home/markus/src/django/django/utils/dateformat.py", line 136, in
O
seconds = self.Z()
File "/home/markus/src/django/django/utils/dateformat.py", line 189, in
Z
offset = self.timezone.utcoffset(self.data)
File "/home/markus/.virtualenvs/machtfit/local/lib/python2.7/site-
packages/pytz/tzinfo.py", line 406, in utcoffset
dt = self.localize(dt, is_dst)
File "/home/markus/.virtualenvs/machtfit/local/lib/python2.7/site-
packages/pytz/tzinfo.py", line 349, in localize
raise AmbiguousTimeError(dt)
AmbiguousTimeError: 2014-10-26 02:40:14.190834
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23714>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Old description:
New description:
When an exception, that would normally - with `DEBUG=True` - be displayed
in the detailed 500 page, occurs during the DST/no-DST ambiguous hour of
the geographical area that is set as TIMEZONE, the handler crashes with
`AmbiguousTimeError`. This seriously limits the ability of many developers
to develop and Django applications for a time span of 1/8760 of the year.
This is unacceptable! ;)
}}}
--
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:1>
Comment (by aaugustin):
Good catch.
Either `django.utils.dateformat.TimeFormat.Z` or
`django.template.defaultfilters.date` should deal with that exception —
probably the latter, as failing silently on errors is a behavior of the
Django Template Language.
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:2>
* type: Uncategorized => Bug
* component: Uncategorized => Template system
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:3>
* cc: tomas.ehrlich@… (added)
* status: new => closed
* resolution: => invalid
Comment:
I can't reproduce this bug at all.
The debug page formats `datetime.datetime.now()` with `{{
server_time|date:'r' }}`. Date format `r` is equivalent to `D, j M Y H:i:s
O` as seen in traceback and `O` call `Z` whitch causes the exception. I
tried to simply format datetime from traceback, but I didn't get any
exception:
{{{#!python
from django.conf import settings
settings.configure(USE_TZ=True, TIME_ZONE='Europe/Amsterdam') # required
for DateFormat, doesn't raise exception for USE_TZ=False neither
import datetime
from django.utils.dateformat import DateFormat
try:
DateFormat(datetime.datetime(2014, 10, 26, 2, 30)).format('Z')
DateFormat(datetime.datetime(2014, 10, 26, 2, 30,
tzinfo=None)).format('Z')
except AmiguousTimeError:
pass
else:
print('Exception wasn't raised')
# Exception wasn't raised...
}}}
There seems to be missing information about timezone, which makes
date&time 2014-10-26 2:30 really ambiguous, but even when I try to format
timezone-naive datetime, it never raises exception.
This bug can actually affects debug page only once a year, when the time
is switched back by one hour. So it's after all just 1/4380 of the year ;)
Could you please provide more information? What TIME_ZONE, USE_TZ settings
do you use and etc.
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:4>
* status: closed => new
* resolution: invalid =>
Comment:
You have to install pytz to see the error.
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:5>
* keywords: => timezone
Comment:
That's right, with installed `pytz` I can see the exception.
Minimal code to reproduce the problem:
{{{#!python
from django.conf import settings
settings.configure(USE_TZ=True, TIME_ZONE='Europe/Amsterdam')
import datetime
from django.utils.dateformat import DateFormat
right_now = datetime.datetime.now().replace(2014, 10, 26, 2, 30)
print(DateFormat(right_now).format('Z'))
}}}
In my opinion it's more serious because it doesn't affect just 500 debug
page, but all templates that uses `date` filter with `r`, `O` or `Z`.
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:6>
* owner: nobody => tricoder42
* status: new => assigned
* needs_tests: 0 => 1
Comment:
Tests are still missings. Should be simple though.
I don't like the fix, but can't figure out anything better. As mentioned
in PR: The except block catching all exceptions is ugly, but I can't rely
on pytz library, which is optional, and therefore I can't catch
pytz.exceptions.AmbiguousTimeError exception.
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:7>
Comment (by mbertheau):
I think handling AmbiguousTimeError in dateformat essentially means we're
making a business logic decision on behalf of the implementor that we
shouldn't make for him - his business logic might dictate a different
decision.
Instead the template code should handle AmbiguousTimeError and silently
return an empty string.
Kudos for fixing the root issue where a naive datetime was put in the
context :) This part can surely be commit separately, because it solves
the first problem that the technical 500 page doesn't work during DST
change.
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:8>
Comment (by aaugustin):
Replying to [comment:8 mbertheau]:
> Instead the template code should handle AmbiguousTimeError and silently
return an empty string.
Yes, that is the correct fix (or at least the fix consistent with how
Django handles ambiguous datetimes in general).
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:9>
Comment (by tricoder42):
I understand that usually templates handle exceptions silently, printing
nothing on error. I just don't like the idea that for one hour a year, the
template won't display datetime at all (for naive datetimes). Yes, we're
making a decision instead of users, but they won't know about this issue,
since it's occurrence is so rare. This isn't a common scenario which is
easily tested.
Maybe at least show warning so user can see in logs what happened and why?
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:10>
Comment (by tricoder42):
Alright, I simplified the solution a little bit. Added explanation into
docs.
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:11>
Comment (by mbertheau):
Reading the code more closely, I'm convinced, that the correct fix is to
change TimeFormat.Z to return an empty string if given a naive datetime.
This is in line with python's strftime, which exhibits the same behaviour.
If you agree, then the scope of this is actually bigger: TimeFormat
shouldn't make up a timezone for anything, if given a naive datetime. This
then concerns TimeFormat.e, TimeFormat.O, TimeFormat.T, TimeFormat.Z and
DateFormat.I.
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:12>
Comment (by mbertheau):
I'm not aware of all the circumstances that TimeFormat is given a naive
datetime - with that caveat I think showing a warning, similar to what
tricoder42 suggested, whenever TimeFormat gets a naive datetime. The
warning could be similar to the datetime model field warning.
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:13>
Comment (by tricoder42):
Just to be precise: The problem occurs only for '''naive''' datetime
during '''DST''' change. For other cases the timezone functions/formats
works fine even for naive datetimes.
And yes, we should fix all other formats as well. I'll do it later.
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:14>
* has_patch: 0 => 1
Comment:
I've updated the pull request, fixed also other `TimeFormat` formats.
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:15>
Comment (by carljm):
I'm not seeing a link to a pull request anywhere in this thread.
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:16>
Comment (by tricoder42):
Replying to [comment:16 carljm]:
> I'm not seeing a link to a pull request anywhere in this thread.
It's in the ticket's header (https://github.com/django/django/pull/3576)
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:17>
* needs_better_patch: 0 => 1
* needs_docs: 0 => 1
Comment:
After discussion on PR, we're waiting for approval from @aaugustin:
Naive datetimes returns empty string for any timezone-related format
specifiers (for the whole year). This is backward-incompatible change
which will be mentioned in docs.
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:18>
* owner: tricoder42 => aaugustin
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:19>
Comment (by Aymeric Augustin <aymeric.augustin@…>):
In [changeset:"c7a6996df7e77bc3b9c5e581e67d766627ebabec"]:
{{{
#!CommitTicketReference repository=""
revision="c7a6996df7e77bc3b9c5e581e67d766627ebabec"
Fixed a crash of the debug page.
During the autumn DST change, the template engine would fail to convert
the naive representation of now when USE_TZ = True. Passing now in UTC
eliminates the issue.
Thanks mbertheau and tricoder42.
Refs #23714.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:20>
Comment (by Tim Graham <timograham@…>):
In [changeset:"c6a49d4f17db4579389e3f0477436f2444dead10"]:
{{{
#!CommitTicketReference repository=""
revision="c6a49d4f17db4579389e3f0477436f2444dead10"
[1.8.x] Fixed a crash of the debug page.
During the autumn DST change, the template engine would fail to convert
the naive representation of now when USE_TZ = True. Passing now in UTC
eliminates the issue.
Thanks mbertheau and tricoder42.
Refs #23714.
Backport of c7a6996df7e77bc3b9c5e581e67d766627ebabec from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:21>
* owner: aaugustin =>
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:22>
Comment (by Aymeric Augustin <aymeric.augustin@…>):
In [changeset:"1014ba026e879e56e0f265a8d9f54e6f39843348" 1014ba02]:
{{{
#!CommitTicketReference repository=""
revision="1014ba026e879e56e0f265a8d9f54e6f39843348"
Fixed debug view crash during autumn DST change.
This only happens if USE_TZ = False and pytz is installed (perhaps not
the most logical combination, but who am I to jugde?)
Refs #23714 which essentially fixed the same problem when USE_TZ = True.
Thanks Florian and Carl for insisting until I wrote a complete patch.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:23>
Comment (by Aymeric Augustin <aymeric.augustin@…>):
In [changeset:"94d13415d81f24743045bcaa43027c737e2bcf5f" 94d1341]:
{{{
#!CommitTicketReference repository=""
revision="94d13415d81f24743045bcaa43027c737e2bcf5f"
[1.8.x] Fixed debug view crash during autumn DST change.
This only happens if USE_TZ = False and pytz is installed (perhaps not
the most logical combination, but who am I to jugde?)
Refs #23714 which essentially fixed the same problem when USE_TZ = True.
Thanks Florian and Carl for insisting until I wrote a complete patch.
Backport of 1014ba026e from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:24>
Comment (by Tim Graham <timograham@…>):
In [changeset:"ca0278f49652c0069d82c08917e0c420dede207b" ca0278f4]:
{{{
#!CommitTicketReference repository=""
revision="ca0278f49652c0069d82c08917e0c420dede207b"
[1.9.x] Fixed debug view crash during autumn DST change.
This only happens if USE_TZ = False and pytz is installed (perhaps not
the most logical combination, but who am I to jugde?)
Refs #23714 which essentially fixed the same problem when USE_TZ = True.
Thanks Florian and Carl for insisting until I wrote a complete patch.
Backport of 1014ba026e879e56e0f265a8d9f54e6f39843348 from master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:25>
* status: new => closed
* needs_better_patch: 1 => 0
* resolution: => fixed
* needs_tests: 1 => 0
* needs_docs: 1 => 0
Comment:
It was fixed by 1014ba026e879e56e0f265a8d9f54e6f39843348 and
c7a6996df7e77bc3b9c5e581e67d766627ebabec.
--
Ticket URL: <https://code.djangoproject.com/ticket/23714#comment:26>