Date.parse() should be localization-aware when passed dd/mm/yyyy format dates

RESOLVED WONTFIX

Status

()

Core
JavaScript: Standard Library
RESOLVED WONTFIX
5 years ago
2 years ago

People

(Reporter: Dean, Unassigned)

Tracking

(Blocks: 1 bug)

22 Branch
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130618035212

Steps to reproduce:

new Date("29/2/2013") yeilds a date object corresponding to May 2nd, 2015, even though it's on a PC in a region where the date format is "dd/mm/yyyy".  The browser is interpreting "29/2/2013" as ((Dec 2nd 2013) + 17 more months).

(Firefox v22 on Windows 7 x64 with regional settings for Australia).


The browser ought to check regional settings when attempting to interpret non-ISO-format dates, and at the very least decide between mm/dd or dd/mm interpretations.

"29/02/2013" in a dd/mm/yyyy region should be parsed to yield March 1st, 2013, or else just be considered invalid; a date in mid-2015 is just crazy!

Updated

5 years ago
Assignee: nobody → general
Component: General → JavaScript Engine
(Assignee)

Updated

4 years ago
Assignee: general → nobody
Component: JavaScript Engine → JavaScript: Standard Library
Assignee: nobody → eric

Comment 1

2 years ago
The problem with localized date-string parsing, is that what will work for the developer, won't necessarily work on the user's side.  That's a recipe for sites breaking in difficult-to-understand ways.  I doubt we'll want to go this direction, but that'll have to wait until there's a standardized Date.parse algorithm.

Note that right now, no browser uses locale-aware parsing here, if I'm not mistaken.  So this proposal *necessarily* must break every browser's current parsing behavior, because existing behavior can only conform either to current unaware behavior, or to proposed locale-aware behavior that differs (or event to something entirely different).  That's not an absolute veto on it, but it's a fairly strong vote that direction.
Thanks for the suggestion, Dean, but I agree with Jeff -- we want date parsing to work the same everywhere, because variations in behavior from browser to browser inevitably lead to mysterious bugs that mainly affect people in minority user demographics, and which are tricky for developers to figure out, reproduce, and regression-test.

Now... it's true that Date.parse() is a pretty bad API. There was never any standard, and as a result every browser does things a bit differently; some give ludicrous answers in some cases, as you discovered. We're currently working on standardizing the behavior so that at least each browser gives the *same* ludicrous answers. But none of this will make Date.parse() suitable for handling dates typed in by users.

For what it's worth, a date-picker is a better mechanism for user input than a text field. Then there is no need for locale-sensitive parsing.

Marking this as RESOLVED WONTFIX.

Web developer involvement is how web standards get better, so don't hesitate to bug us again! Cheers. :)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
Assignee: eric → nobody
You need to log in before you can comment on or make changes to this bug.