i18n versions do not parse months properly

[lllopo]

Hi,
I've noticed that there is something wrong when parsing i18n months names. Did dome digging and basically got to the following :

1. Date.parse does a "s = $D.Parsing.Normalizer.parse(parseUtils.removeOrds(s));" which replaces the i18n month names with the english ones, based on the basicReplaceHash.
2. The grammar parser though, uses the i18n regular expressions to match the month name.

The result is the if the original date is something like "01 Juli 1975", it gets converted to "01 July 1975" by the normalizer and then it is matched against "/jul(i)/", which of course does not work properly. I made a fix to the basicReplaceHash, making it to use as keys the i18n month names, but I"m not sure this is the right thing to do .... it seems to be working though :-).

[abritinthebay]

Good catch. I need to spend some quality time working on this. Issues like this specifically.

[NorbertTUZA]

Hi,
I can confirm Illopo's catch.
I've tried to feed French date piece like '2 juil' to Date.parse() and it didn't return a valid date like in case of English.
I figured out the same that s = $D.Parsing.Normalizer.parse(parseUtils.removeOrds(s)); beside removing ordinal dates it returns English localized date, and next step grammar based parser won't find correct date so will try to parse with native. I do the modification and then it works properly:

// find ordinal dates (1st, 3rd, 8th, etc and remove them as they cause parsing issues)
//s = $D.Parsing.Normalizer.parse(parseUtils.removeOrds(s)); //removed
s = parseUtils.removeOrds(s); // newly added
d = parseUtils.grammarParser(s);
if (d !== null) {
return d;
} else {
return parseUtils.nativeFallback(s);
}

[abritinthebay]

Removing the Normailizer will break MANY other things though (like.. a lot of things, all over the place).

Good catch tho - the Normalizer should respect local strings.