New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 618595 link

Starred by 3 users
Status: Assigned
Owner:
yangguo@chromium.org
Cc:
jochen@chromium.org
bmeu...@chromium.org
domenic@chromium.org
█ littledan@chromium.org
adamk@chromium.org
gsat...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: ----



Sign in to add a comment

Track usage of implementation-specific heuristics in Date.parse

Project Member Reported by yangguo@chromium.org, Jun 9 2016 
Excerpt from ECMA262 on Date.parse:

[...]
The function first attempts to parse the format of the String according to the rules (including extended years) called out in Date Time String Format (20.3.1.16). If the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats. Unrecognizable Strings or dates containing illegal element values in the format String shall cause Date.parse to return NaN.


There is some efforts underway to specify the implementation-specific fall back behavior: https://bugzilla.mozilla.org/show_bug.cgi?id=1274354


The reason cited is cross-browser compatibility. However, it would make sense to find out how much this implementation-specific heuristic is used in the first place.

Comment 1 by adamk@chromium.org, Jun 9 2016

Cc: littledan@chromium.org
Components: Blink>JavaScript>Language
Project Member

Comment 5 by bugdroid1@chromium.org, Jun 22 2016 

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/8b67a002231c222314170a13187e31a2b361ef91

commit 8b67a002231c222314170a13187e31a2b361ef91
Author: yangguo <yangguo@chromium.org>
Date: Wed Jun 22 18:06:25 2016

Only count legacy parser usage if legacy parser had effect.

We would otherwise also count if its just trimming whitespaces.

R=adamk@chromium.org
BUG=chromium:618595

Review-Url: https://codereview.chromium.org/2080183003
Cr-Commit-Position: refs/heads/master@{#37197}

[modify] https://crrev.com/8b67a002231c222314170a13187e31a2b361ef91/src/dateparser-inl.h
[modify] https://crrev.com/8b67a002231c222314170a13187e31a2b361ef91/test/cctest/test-date.cc

Comment 6 by littledan@chromium.org, Jun 22 2016

Cc: domenic@chromium.org
Although users should use something like Moment.js to parse dates, we seem to be getting a steady stream of bugs on our end reporting that our Date.parse implementation does not parse certain dates that other browsers parse. Some bugs that I've looked at with date parsing:

https://bugs.chromium.org/p/chromium/issues/detail?id=589858#c2 -- pushed back
https://bugs.chromium.org/p/v8/issues/detail?id=4987 -- pushed back
https://bugs.chromium.org/p/chromium/issues/detail?id=422858 -- fixed

Overall, based on these bug reports and the bug reports that Firefox and Edge are getting, a number of users seem to have an expectation, which seems reasonable to me, that Date.parse will have the same behavior across different browsers.

Although it's unfortunate that we're in a state where we are more tolerant with dates than just ISO 8601, I think this is analogous to other situations in the web platform. For example, for HTML, the emphasis of standards bodies used to be encouraging users to run HTML validators, while web browsers permitted more broad HTML syntax. Eventually, WHATWG standardized a more tolerant, but well-defined HTML parser. It's a painful process, but the definition helped iron out differences between browsers in these edge cases. Subtle, unexpected differences in behavior between browsers can also sometimes result in security bugs, especially when it comes to parsing.

In this case, the existence of all these bug reports gives some circumstantial evidence that the legacy date path is used. The new UseCounter data will also give further information to see if my evaluation of that circumstantial evidence is accurate.

If it does turn out that we can't just deprecate the legacy Date parser, I think the next step would be for us and other browsers to collect UseCounters on various particular cases, especially the ones which differ between browsers. For example, we permit arbitrary junk letters after parsing the date, and other browsers do not, last time I tested--should this be part of a standard? There are probably many of these cases to identify based on a cross-browser comparison.

Comment 7 by yangguo@chromium.org, Jul 12 2016 

UMA reports a whopping 65% for the legacy date parser usage on dev channel.

Comment 8 by adamk@chromium.org, Aug 8 2017 

Is there more work to do here? Or do the UMA numbers from #7 mean we should close this out?

Comment 9 by littledan@chromium.org, Aug 17 2017 

It would be nice to track how much we'd have to stray out of a proposed more lenient grammar, but such a grammar has not yet been proposed unfortunately.

Comment 10 by benhenry@google.com, Jan 11

Labels: Pri-2
Setting defect without priority to Pri-2.
►

Sign in to add a comment