1693692 - Javascipt Date constructor produced a wrong date from "dd-mmm-yyyy" format

Status: RESOLVED DUPLICATE of bug 1439800

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

Description

[[e-mail]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

Create a date from a string in the date format "dd-mmm-yyyy"
eg var mydate = new Date("01-Mar-2021")
var myYear = myDate.getFullYear()

Actual results:

no Error is reported
myYear returns -2021
Other functions produce wrong results eg toLocaleDateString returns a date in the next year.
JSfiddle set up here (in typescript but also checked in straight Javascript)
https://jsfiddle.net/Senachie/nx859jmd/188/
Checked version are noted in the above page FF 32bit 82->85
FF dev version 86.0b
It works correctly in Opera and Chrome

Expected results:

Either: throw an error for unsupported format
or return the year correctly (2021)

Comment 1

[[e-mail]]

Use this non-specific link to get the latest save of the jsfiddle demo:
https://jsfiddle.net/Senachie/nx859jmd

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::JavaScript Engine' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[Thorin [:thorin]]

duplicate of Bug 1600902 which was closed as duplicate of Bug 1515318

Comment 4

[[e-mail]]

Apologies I missed the originals searching for issues with "Date Constructor"
"dd-mmm-yy" (or yyyy) is no longer a standard format, but was in the standard Office formats in this locale (en-AU) for decades as "medium date"
It is the shortest date text format unambiguous to humans across different locales, so there is a case for adding it.
It still comes in in data entered by humans in my locale.
If its not supported it should throw. It cost us a few hours work to track down date corruption in DB.
Chrome is now parsing it correctly.

Comment 5

[Jason Orendorff [:jorendorff]]

Thank you for the bug report.

You're right that the current behavior is absurd. We should either parse it the way any human being would expect, or treat it as an unsupported format. Unfortunately, the standard says to produce a NaN date object in that case rather than throw:

Strings that are unrecognizable or contain out-of-bounds format element values shall cause Date.parse to return NaN.

As there is no standard behavior for the Date constructor (outside of the standard Date format), this isn't a super high priority for us. If there were a precise standard, we'd implement it.

Comment 6

[[e-mail]]

Thank you for the feedback.

Throw was used generically, returning NaN would be a good resolution, albeit perhaps more difficult to implement than treating "-" as a separator in both positions instead of just the first.
The real problem is that the corrupted date gets translated back to a reasonable but incorrect date when it round-trips back to a text string.

Its no longer an issue for us as it has been dealt with at the front end. (Just converting all "-" chars to spaces before conversion is one simple solution).
The reason this bug showed up recently is because many client tools are currently being migrated to web applications, and the dates in the client are often converted back to text on the way to a DB via a post or put (somewhere in the call stack).
I am surprised it has not come up more often before now.