#10335: tzinfo.py should use getdefaultencoding instead of getdefaultlocale[1]
-------------------------------------+--------------------------------------
Reporter: gthb | Owner: nobody
Status: new | Milestone: 1.1
Component: Core framework | Version: 1.0
Resolution: | Keywords: locale encoding
getdefaultlocale getdefaultencoding mac
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
-------------------------------------+--------------------------------------
Comment (by gthb):
Sorry for the late reply, I hadn't set up an email address for
notifications.
In response to mtredinnick: good point about {{{setdefaultencoding}}}, I
didn't know that. A few notes:
1. The above patch (second one) only calls {{{getdefaultencoding}}}, and
it does so only if the present implementation fails in a way that will
break Django. The {{{setdefaultencoding}}} call would be made consciously
by the user as a workaround, only upon encountering this problem, and they
will only encounter it if {{{ascii}}} is not good enough.
2. Based on a quick grep, this {{{DEFAULT_ENCODING}}} is used in only one
place in all of Django, in this same file:
{{{
#!python
return smart_unicode(time.tzname[self._isdst(dt)],
DEFAULT_ENCODING)
}}}
Standard timezone names are probably all representable in {{{ascii}}}
anyway, so maybe {{{ascii}}} is good enough here. I suppose
{{{DEFAULT_ENCODING}}} (or timezones) must have been used in more places
when I ran into this some weeks ago, because Django broke right away, but
now it breaks only when I add something involving timezones. I now
reproduce it with a view that does this:
{{{
#!python
from django.utils.tzinfo import LocalTimezone
from datetime import datetime
LocalTimezone(datetime.now())
}}}
So maybe it is enough to settle for {{{ascii}}}, when the default locale
method fails or returns a bogus encoding.
3. I will attach a third, even more conservative patch, that just adds the
codec lookup within the first try block. The trouble with Mac OS X in the
Icelandic locale is that {{{locale.getdefaultlocale()[1]}}} ''does not
raise an exception'' but instead just returns an encoding name that will
result in an exception ''later'' when used. This most minimal patch just
makes the failure come up right away, so that the {{{except}}} block deals
with it. This way the comment "Any problems at all determining the locale
and we fallback" is made more true, with no other effects.
4. On correctness: the premise "since the user's system is set up to
return their preference" assumes too much. My locale preference for the
overall OS is not necessarily my locale preference for Django. In the case
of Mac OS X I don't get to separate the two because of the hardcoding
explained above. And if my preference is a locale with a Mac-specific
encoding not recognized by Python (such as the Icelandic locale), then
that triggers a serious problem in {{{django.utils.tzinfo}}}. The problem
is not that ''Django'' doesn't understand the answer, but that ''Python
itself'' doesn't. This problem can be worked around with one of the
options I propose here.
--
Ticket URL: <http://code.djangoproject.com/ticket/10335#comment:5>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
