This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: locale specific problem in test_strftime.py
Type: Stage:
Components: Library (Lib) Versions: Python 2.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: brett.cannon Nosy List: brett.cannon, quiver
Priority: low Keywords:

Created on 2004-01-24 13:21 by quiver, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
test_strftime.py.diff quiver, 2004-01-24 13:21
escapestr.diff brett.cannon, 2004-03-20 17:32 Escape regexes properly
after_patch quiver, 2004-03-21 02:19 result after patch applied
before_patch quiver, 2004-03-21 02:23 result before patch applied
Messages (7)
msg19805 - (view) Author: George Yoshida (quiver) (Python committer) Date: 2004-01-24 13:21
test/test_strftime.py compares an expectation and a 
result by regular expressions, but the pattern isn't 
escaped. So if the expectation includes a metacharacter,
  expectation == result
and
  re.match(expectation, result)
do not always return the same value.

In my case on Japanese Windows, time.tzname returns
  ('\x93\x8c\x8b\x9e (\x95W\x8f\x80\x8e\x9e)', '\x93
\x8c\x8b\x9e (\x95W\x8f\x80\x8e\x9e)')
The output contains parentheses. 
This resuls in a message:
  Conflict for nonstandard '%Z' format (time zone name):
    Expected “Œ‹ž (•W€Žž), but got “Œ‹ž (•W€Žž)
re.match(foo, bar) != (foo == bar)

One workaround I can think of is changing re.match(e
[1], result) back to result == e[1].
msg19806 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2004-01-27 08:28
Logged In: YES 
user_id=357491

Does anyone know why we even have test_strftime?  It isn't like 
we have our own implementation and there are basic tests in 
test_time to make sure the wrapper around the C function works.  
I know the test module says it is for sanity checks, but if it fails 
legitimately on a platform there is not much we can do about it.  
Is this for Jython or something?
msg19807 - (view) Author: George Yoshida (quiver) (Python committer) Date: 2004-01-29 11:54
Logged In: YES 
user_id=671362

> Is  this for Jython or something?
No, it's Python 2.3.3 on Windows 2000.

time zone is classified as non standard(unpredictable) so it 
might be difficult to make test_stftime.py to support all 
locales. There are so many issues.

FYI, I checked time.tzname on other platforms.

# Jython
Jython 2.1 on java1.4.2 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> import time
>>> time.tzname
('JST', 'JST')  # Japanese Standard Time

# Linux
On RHL 9.0(Python 2.2/2.3), time.tzname returns ('JST', 'JST').

They pass the test.
msg19808 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2004-01-30 02:23
Logged In: YES 
user_id=357491

That's not what I meant by the comment; sorry for not being 
clearer.  I meant is whether test_strftime's existence is because of 
Jython.
msg19809 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2004-03-20 17:32
Logged In: YES 
user_id=357491

George, can you apply the attached  patch and let me know if it solves 
the problem?
msg19810 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2004-03-20 23:24
Logged In: YES 
user_id=357491

Fixed in rev. 1.29 of Lib/test/test_strftime.py in Python 2.4 and rev. 
1.27.16.1 for Python 2.3 .
msg19811 - (view) Author: George Yoshida (quiver) (Python committer) Date: 2004-03-21 02:19
Logged In: YES 
user_id=671362

Thanks, Brett.
The problem has been solved.

I uploaded the output of test_strftime.py just for 
confirmation. 
History
Date User Action Args
2022-04-11 14:56:02adminsetgithub: 39861
2004-01-24 13:21:27quivercreate