As discovered in this comment, other engines only look at the first 3 letters of the month name to make a determination.

> eshost -te 'new Date("8 sepxxx 2021")'

This will require a modification of a 3 different parts of the code which check for the month name, including code which will be landing in bug 1617562, so we should wait for that before addressing this. We might be able to refactor these month name checks to use a common function.

(currently phabricator email isn't working, so commenting here as well)

posted the review comments on the revision.
can you address them?

I know Date.parse is terrible, but this one kind of annoys me. It basically makes parsing non-English dates a coin toss. Because I assume it means we would accept the Spanish name "marzo", but not "abril".

(In reply to Tom S [:evilpie] from comment #3)

I know Date.parse is terrible, but this one kind of annoys me. It basically makes parsing non-English dates a coin toss. Because I assume it means we would accept the Spanish name "marzo", but not "abril".

Do you think we should keep the current behavior?

The current behavior also has the "coin toss" characteristics if the non-english month name is used as abbrev ("mar" and "abr" in spanish case),
so the difference happens only when the month name is written as 4+ characters.
And given chrome and safari agrees on the first 3 characters, I assumed aligning with them won't harm much.

Just to verify my understanding, we currently only support "Apr", "Mar" (so no following letters) which exactly match the English abbreviations? This would add the case where we would allow words like "Apron" or "Marching" ? I think there a somewhat significant difference between allowing technically valid abbreviations vs. matching a random subset of words.

Considering that Chrome/Safari apparently already support this misbehavior we probably have to support it anyway ..

Firefox's current behavior is to support all abbreviations from 3 chars up to the entire word, e.g. "Aug", "Augu", "Augus", and "August".

I agree that the Chrome and Safari behavior makes less sense, this bug is only for parity.

https://hg.mozilla.org/mozilla-central/rev/9aa0b8954c6a

MDN docs work for this can be tracked in https://github.com/mdn/content/issues/31930.
This is a release note and a couple of examples. There is no compatibility data change because there is no expected format for the "non-standard string formats".