Closed Bug 1235045 Opened 10 years ago Closed 3 years ago

Date Formats Support

Categories

(Core :: JavaScript: Standard Library, defect)

Product:
Core
Component:
JavaScript: Standard Library
Version:
44 Branch
Platform:
All
macOS
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: dron.rathore, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [webcompat])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36 Steps to reproduce: Currently the only format that Date constructor takes is : yyyy-mm-dd and all other are just "Invalid Date" new Date("dd-mm-yyyy") new Date("yyyy-dd-mm") new Date("mm-dd-yyyy") Actual results: Above all throws "Invalid Date" error. Expected results: Well I tried the same in Chrome and they just worked! As there is no as such universal format that everyone "should" use in the WebApps they build, we should extend support of other Date formats too.
Component: Untriaged → General
OS: Unspecified → Mac OS X
Hardware: Unspecified → All
Component: General → JavaScript Engine
Product: Firefox → Core
Blocks: sm-date-parse
Component: JavaScript Engine → JavaScript: Standard Library
See Also: → https://github.com/webcompat/web-bugs/issues/24515
Whiteboard: [webcompat]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Webcompat Priority: --- → ?

See bug 1547409. Migrating whiteboard priority tags to program flags.

Webcompat Priority: ? → revisit
Severity: normal → S3
Webcompat Priority: revisit → ---

This bug is a bit dated; as of now Chrome supports the following formats:

Format Chrome Firefox
MM-DD-YYYY ✔️ ❌
YYYY-MM-DD ✔️ ✔️

and rejects the following (two of which are suggested in this bug):

Format Chrome Firefox
DD-MM-YYYY ❌ ❌
YYYY-DD-MM ❌ ❌

If these were to be allowed there would be ambiguity in cases where the day is <= 12. Neither Chrome nor Firefox allow these formats with either - or / as the delimiter. While these formats may be preferred in some regions, it would be impossible to have it both ways without picking a default in the case of ambiguity which would cause much confusion; I think rejecting these formats is a necessary evil.

This leaves MM-DD-YYYY which Firefox does not accept but should; for this I refer you to Bug 1275498 which is dedicated to this format.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.