There are a couple of ways I can think of off the top of my head to solve this issue.

1) Update the `new Date()` call to match up with the other JS engines which would be invalid date.
2) Use the first Month found in the string in this case `Sep` rather then `Jun`. This could cause parsing issues similar to this one.
3) Pick the more precise of the dates. This has the downside of being slower
4) Leave it the way it is.

Results from different browsers:

Test code:
console.log(new Date("Fri Sep 14 2018 12:44:48 GMT+0200 (Central European Summer Time) junk").toString());

Firefox:
"Invalid Date"

Edge:
"Invalid Date"

IE:
"Invalid Date"

Safari:
"Invalid Date"

Chrome:
"Thu Jun 14 2018 03:44:48 GMT-0700 (Pacific Daylight Time)"

Moved issue v8:8289 to now be issue chromium:897083.

Jakob is this a dupe?

#5: Depends on how you look at it:

- v8:8187 summarizes as: "Sep 14 junk" should be rejected as "Invalid Date".
- this here summarizes as: If Chrome chooses not to reject "Sep 14 junk", then it should be parsed as "September", not as "June".

Which means if we close v8:8187 as WAI, then this issue deserves its own consideration. If we decide to fix v8:8187 as suggested, then we can either close this one as Invalid/Obsolete or dupe it back into v8:8187.

Personally I think rejecting such strings sounds reasonable (as v8:8187 suggested), but I can't judge the compatibility risk.

I'm personally of the mind that because this is an "Invalid Date" in all engines other then V8 it should be changed for cross browser compatibility.