Closed Bug 1870570 Opened 5 months ago Closed 5 months ago

Date.parse accepts incomplete time zone abbreviations and AM/PM

Categories

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

defect

Tracking

()

RESOLVED FIXED
123 Branch
Tracking Status
firefox123 --- 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)

We accept partial time zone and AM/PM, which other engines do not:

Input JavaScriptCore SpiderMonkey V8
"9/26/95 g" Invalid Date Mon Sep 25 1995 17:00:00 GMT-0700 (Mountain Standard Time) Invalid Date
"9/26/95 gm" Invalid Date Mon Sep 25 1995 17:00:00 GMT-0700 (Mountain Standard Time) Invalid Date
"9/26/95 gmt" Mon Sep 25 1995 17:00:00 GMT-0700 (Mountain Standard Time) Mon Sep 25 1995 17:00:00 GMT-0700 (Mountain Standard Time) Mon Sep 25 1995 17:00:00 GMT-0700 (Mountain Standard Time)
"9/26/95 c" Invalid Date Mon Sep 25 1995 22:00:00 GMT-0700 (Mountain Standard Time) Invalid Date
"9/26/95 cs" Invalid Date Mon Sep 25 1995 23:00:00 GMT-0700 (Mountain Standard Time) Invalid Date
"9/26/95 cst" Mon Sep 25 1995 23:00:00 GMT-0700 (Mountain Standard Time) Mon Sep 25 1995 23:00:00 GMT-0700 (Mountain Standard Time) Mon Sep 25 1995 23:00:00 GMT-0700 (Mountain Standard Time)
"9/26/95 10:00 a" Invalid Date Tue Sep 26 1995 10:00:00 GMT-0700 (Mountain Standard Time) Invalid Date
"9/26/95 10:00 am" Tue Sep 26 1995 10:00:00 GMT-0700 (Mountain Standard Time) Tue Sep 26 1995 10:00:00 GMT-0700 (Mountain Standard Time) Tue Sep 26 1995 10:00:00 GMT-0700 (Mountain Standard Time)

This is causing problems making bug 1870434's patch play nice with naturalSort.

We only need to accept partial keywords for day of week, which it looks like we will soon be dropping support for at this point in the format, see bug 1862922. If we wish to tackle these before then, it looks like we will need to separate the day of week logic from the rest of the keywords.

Do you think it's okay to drop support for these formats without running telemetry first? Unlike bug 1862922, these formats are likely to be mistakes, rather than a valid keyword in an odd location, and no other browsers support them, so I think risk of breaking things here is low...

Flags: needinfo?(arai.unmht)

I agree that the risk of breakage is sufficiently low, and this won't need telemetry.

Flags: needinfo?(arai.unmht)
Priority: -- → P3
Assignee: nobody → vinny.diehl
Status: NEW → ASSIGNED
Pushed by arai_a@mac.com:
https://hg.mozilla.org/integration/autoland/rev/309a7d377822
Only allow exact matches for time zone and AM/PM keywords r=arai
Status: ASSIGNED → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → 123 Branch
Keywords: parity-safari

Vinny Diehl, what kind of documentation might be needed here?

:vmakeev, here are some examples of dev docs for previous Date.parse changes:

Comment 0 as well as the tests associated with this patch give some insight as to the type of cases that are newly disallowed. Note that this patch drops support for some formats rather than adding new ones.

I would suggest something to the effect of:

  • Incomplete time zone (e.g. "1/1/70 gm") or AM/PM (e.g. "1/1/70 10:00 a") are no longer accepted.

I'm unsure if this should go under the "JavaScript" header as with previous changes, or under a separate "Removals" subheader, I will leave that up to you and the MDN team.

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

Attachment

General

Creator:
Created:
Updated:
Size: