[Mono-bugs] [Bug 76938][Min] New - DateTime._Parse* internal methods are buggy in some (possibly-theoretical) locales

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by danw at novell.com.

http://bugzilla.ximian.com/show_bug.cgi?id=76938

--- shadow/76938	2005-12-07 13:51:07.000000000 -0500
+++ shadow/76938.tmp.24190	2005-12-07 13:51:07.000000000 -0500
@@ -0,0 +1,36 @@
+Bug#: 76938
+Product: Mono: Class Libraries
+Version: unspecified
+OS: 
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Minor
+Component: CORLIB
+AssignedTo: mono-bugs at ximian.com                            
+ReportedBy: danw at novell.com               
+QAContact: mono-bugs at ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: DateTime._Parse* internal methods are buggy in some (possibly-theoretical) locales
+
+DateTime._ParseString and _ParseEnum check if a given string is a
+case-insensitive prefix match of another, and if so, return the length
+of the match.
+
+However, they assume that the length of the match in the input string
+is the same as the length of the string it was matched against. This
+isn't always a valid assumption though. Eg, the the 8-character input
+"SCHEISSE" is a case-insensitive match for the 7-character string
+"Scheiße" according to German string-comparison rules. _ParseString and
+_ParseEnum would return the wrong number of characters to skip over in
+this case, causing the rest of the parse to get out of sync and fail.
+
+The good news is that none of the German month or day names actually have
+an "ß", so there might not be any problem. (I only found the bug because
+I needed code to do this for a similar situation, and realized it was
+fairly annoying and tricky to solve correctly, and went to DateTime
+hoping to find code that I could steal. :-) I have no idea if there are
+other locales that might be getting messed up by similar issues though.