Closed Bug 1862910 Opened 5 months ago Closed 5 months ago

Make Date.parse only check first 3 characters of month name

Categories

(Core :: JavaScript: Standard Library, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
122 Branch
Tracking Status
firefox122 --- fixed

People

(Reporter: vinny.diehl, Assigned: vinny.diehl)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-complete, parity-chrome, parity-safari)

Attachments

(1 file)

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")'
Engine Result
JavaScriptCore Wed Sep 08 2021 00:00:00 GMT-0700 (Mountain Standard Time)
SpiderMonkey Invalid Date
V8 Wed Sep 08 2021 00:00:00 GMT-0700 (Mountain Standard Time)

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.

See Also: → 1730155
Priority: -- → P3
Assignee: nobody → vinny.diehl
Status: NEW → ASSIGNED

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

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

Flags: needinfo?(vinny.diehl)

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.

Flags: needinfo?(evilpies)
Flags: needinfo?(vinny.diehl)

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 ..

Flags: needinfo?(evilpies)

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.

Pushed by arai_a@mac.com:
https://hg.mozilla.org/integration/autoland/rev/9aa0b8954c6a
Make Date.parse only check first 3 characters of month name r=arai
Status: ASSIGNED → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → 122 Branch
Keywords: dev-doc-needed

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".

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

Attachment

General

Creator:
Created:
Updated:
Size: