Bug 658785 - strptime matches English month names regardless of locale
Summary: strptime matches English month names regardless of locale
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: glibc
Version: 5.5
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Andreas Schwab
QA Contact: qe-baseos-tools-bugs
Depends On:
TreeView+ depends on / blocked
Reported: 2010-12-01 09:35 UTC by Göran Uddeborg
Modified: 2016-11-24 16:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-12-01 09:46:59 UTC
Target Upstream Version:

Attachments (Terms of Use)
Simple test case. (530 bytes, text/x-csrc)
2010-12-01 09:35 UTC, Göran Uddeborg
no flags Details

Description Göran Uddeborg 2010-12-01 09:35:58 UTC
Created attachment 463929 [details]
Simple test case.

Description of problem:
When using strptime() to match month names, it seems the English names are considered irrespective of locale.

Version-Release number of selected component (if applicable):

How reproducible:
Every time

Steps to Reproduce:
1. Compile the attatched test case: make cb
2. Run it: ./cb
Actual results:
Unexpected match: tm.tm_mon = 9

Expected results:
No match, ok!

Additional info:
Combined with the non-greedy matching in current RHEL5 glibc, see bug 657570, this causes problems trying to match November in the Finnish locale.  But even if that bug is fixed, there could be locales where this still cause incorrect behaviour.  If there is a locale where "ma" is a short name for a month, for example.

Comment 1 Andreas Schwab 2010-12-01 09:46:59 UTC
This is by design.

Comment 2 Göran Uddeborg 2010-12-01 21:28:35 UTC
Is there some rationale written for that somewhere?

It did look like a bug to me.  If I was parsing for a date in a particular locale, I would have expected to discover if I got an input which wasn't a date in that locale, but maybe happened to match English.  And it is not without risks.  One example is as I explained in the "additional info" section.

Note You need to log in before you can comment on or make changes to this bug.