Closed GoogleCodeExporter closed 8 years ago
Looks like windows-only bug or I couldn't reproduce it on Linux system, but
could on Windows one.
There are two options: wait for @Matt http module and cache system refactoring
or quick fix current behavior. I'm for first one.
Original comment by kxepal
on 21 Feb 2012 at 3:46
Something is missing: the default locale, or the choosen locale shouldn't be in
english. Since the locale name is OS dependant (fr_FR on Linux, French_France
on Windows), I didn't include it in the example.
Original comment by emmanuel...@gmail.com
on 21 Feb 2012 at 4:00
This is important note, thanks!
# Quick fix for your example:
import time
from email.Utils import parsedate
from datetime import datetime
def cache_sort(i):
t = time.mktime(parsedate(i[1][1]['Date']))
return datetime.fromtimestamp(t)
# And monkey-patch cache_sort function:
couchdb.http.cache_sort = cache_sort
This should work! At least for me with ('ru_RU', 'cp1251') locale info. I'll
prepare patch and tests later.
Original comment by kxepal
on 21 Feb 2012 at 4:20
Original comment by kxepal
on 5 Oct 2012 at 8:58
Anyone has ideas how to write test case that depended on some non en_US locale?
If I'll set some ru_RU this test will pass for me, but not for those who hasn't
this locale enabled. Same thing is about fr_FR one that is missed for me.
Original comment by kxepal
on 10 Oct 2012 at 8:44
Maybe do some trickery with unittest.skip? Check for the presence of the
locale at module import time, and conditionally skip the test?
Original comment by wickedg...@gmail.com
on 11 Oct 2012 at 6:02
unittest.skip will bring unittest2 dependency which couldn't help with prevent
problem in future. Also it's impossible to check locale because it could not be
available - as for me I have ('ru_RU', 'cp1251') while 'fr_FR' is missed for me.
There are two solutions:
1. Make tests for Windows only against ANSI encoding since it brings a problem,
while Linux long ago has *.UTF-8 system encoding by default.
2. Since this bug dependent on OS environment AND processed Date value follows
well known rules[1][2] it will be right decision to use right ways[3][4][4] to
parse such value. Tests are redundant in this case since there is actually
nothing to test - Python functions are well tested by his community and bug
occurs not because of couchdb-python logic code.
As for me, second variant is better because:
- it follows RFC like parsed value does;
- it is not locale dependent;
- I don't see any portable and stable ways to test locale specific things
without providing some dependency overhead (babel and mock may help there);
Patch attached. Thoughts?
[1]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.18
[2]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1
[3]: http://docs.python.org/library/email.util.html#email.utils.parsedate
[4]:
http://stackoverflow.com/questions/1471987/how-do-i-parse-an-http-date-string-in
-python
[5]:
http://stackoverflow.com/questions/225086/rfc-1123-date-representation-in-python
Original comment by kxepal
on 11 Oct 2012 at 11:35
Attachments:
This issue was closed by revision b7ada64cd590.
Original comment by kxepal
on 12 Oct 2012 at 8:02
Original issue reported on code.google.com by
emmanuel...@gmail.com
on 21 Feb 2012 at 3:26Attachments: