Bug 658785

Summary: strptime matches English month names regardless of locale
Product: Red Hat Enterprise Linux 5 Reporter: Göran Uddeborg <goeran>
Component: glibcAssignee: Andreas Schwab <schwab>
Status: CLOSED NOTABUG QA Contact: qe-baseos-tools-bugs
Severity: medium Docs Contact:
Priority: low    
Version: 5.5CC: fweimer
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-12-01 09:46:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Simple test case. none

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):
glibc-2.5-49.el5_5.7

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.