Closed Bug 671312 Opened 13 years ago Closed 13 years ago

Javascript DATE constructor will not accept date strings containing dashes

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Version:
5 Branch
Platform:
All
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: djo_34, Unassigned)

References

Details

(Whiteboard: js-triage-done [webcompat]) 

User Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E; Tablet PC 2.0)

Steps to reproduce:

The question is what did you do?

     var birthdate = new Date( '05-24-1978 11:28' );

returns invalid date in Firefox 5.

     var birthdate = new Date( '05/24/1978 11:28' );

works OK. However, a dash (-) separator works in every other browser, and every other version of Firefox.

Suddenly, dashes are not accepted separators in Firefox 5.

You realize that thousands of applications will stop working properly in Firefox 5 because of one idiot. Nice job. Please stop developing. You just make more work for Web application developers that need to add special code to make things work in your buggy browser.


Actual results:

It stopped working.


Expected results:

It should return a valid date object.
Example/(reduced) Testcase/URL in a broader Context?

... and drop that being-pissed-sounding Tone/Mood/Attitude, please, since that leads to nowhere.

https://developer.mozilla.org/en/Bug_writing_guidelines
OS: Other → Windows 7
I've tried to write a test case, but I can't find any Firefox version at all that works with dashes as in comment 0:

<html>
  <body>
    <script type="text/javascript">
      var d1 = new Date('05/24/1978 11:28');
      var d2 = new Date('05-24-1978 11:28');
      document.write("<p>" + d1 + "<br>" + d2 + "</p>");
    </script>
  </body>
</html> 

I always get:
Wed May 24 1978 11:28:00 GMT+0100 (CET)
Invalid Date

The documentation says the dateString should be an IETF-compliant RFC 1123 timestamp: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date
That probably means the string should look like a time and date specification as in RFC-822 Section 5, but with a four digit year.

When I tried to use ISO 8601, as in the ECMA standard, then dashes work:
var d2 = new Date('1978-05-24T11:28');
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
Whiteboard: js-triage-needed
djo_34: Bugs like this are a problem for everyone, and we'd love to work with you to solve them (so do please try to be nice to us - we're people too!)


(Now for the slightly more formal part).

ES5 15.9.1.15 says dates should be in the form: "1978-05-24T18:28:00.000Z". We parse that fine. |new Date(x)| should give the same result as Date.parse(x), which (15.9.4.2) says

"The function first attempts to parse the format of the String according to the rules called out in Date Time String Format (15.9.1.15). If the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats."

So we're not required to support it by ES5, but can choose to.

What about our docs (https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date/parse)? They say we support "RFC 1123 Section 5.2.14 and elsewhere", which is not the format from comment 0.

Firefox 3.6.19 doesn't support it either. I get "Invalid date" same as comment 2 (thanks Thomas, I'm assuming you checked FF4). So no regression here.

It is curious that we support the same Date with slashes but not dashes, but I don't think that's enough to call this a bug.

djo_34: if you know what versions used to support this syntax, please feel free to repoen this.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
Whiteboard: js-triage-needed → js-triage-done
Whiteboard: js-triage-done → js-triage-done [webcompat]
You need to log in before you can comment on or make changes to this bug.