3

Chrome returns valid date for string "FY 2000" instead of invalid date while others browsers are correctly returning "invalid date"

Fiddle link: https://jsfiddle.net/Lddr79ek/

Code:

function isDate(value)
{
    return new Date(value).toString()!= "Invalid Date");
}

is this an issue in chrome browser ?

Edit The problem is the reported behavior breaks our product only in chrome browser. I checked other answers in SO but they are also not working in chrome.

Kira
  • 1,403
  • 1
  • 17
  • 46
  • Short answer: Don't check for a invalid date by comparing a `Date` to a string. I checked your snippet on Edge (my current browser at the moment) and I got back a `Date` object when a called `new Date()`. – Tim Biegeleisen Aug 29 '17 at 05:31
  • @Tim Given answers are not working in chrome – Kira Aug 29 '17 at 05:35
  • Then you should give us a _reproducible_ example of code which can be easily run on Chrome by another SO user. Your current approach is not ideal on any browser AFAIK, so that it doesn't work on Chrome is a moot point. – Tim Biegeleisen Aug 29 '17 at 05:36
  • @all, why no one is understanding the question correctly ? Try the fiddle in different browsers. You will find that all browsers except chrome will return "Invalid date" – Kira Aug 29 '17 at 05:45
  • @Claies, my point is "none of those answers are working in chrome now" – Kira Aug 29 '17 at 05:48
  • I tried before posting the question. Not all 41, only those use native JavaScript – Kira Aug 29 '17 at 05:53
  • 2
    Chrome sees to accept practically anything, `'In the year 2525'` is parsed as a valid date as well. – david25272 Aug 29 '17 at 05:57
  • 1
    @Kira—this is a duplicate. Since ECMAScript Ed. 5, the built-in parser is only required to parse the format specified in the standard (a version of ISO 8601 extended). Anything else is entirely implementation dependent, that is, an implementation can parse the string however it wants. Before Ed. 5, there was no requirement to parse any particular format at all. – RobG Aug 29 '17 at 05:59
  • @RobG I don't understand how ECMA standard makes my question duplicate. Your comment looks like an explanation to my question – Kira Aug 29 '17 at 06:00
  • @RobG, Also I am using Date constructor not Date.parse method. That is the standard you have mentioned is not applicable to the question – Kira Aug 29 '17 at 06:10
  • So far http://www.ecma-international.org/ecma-262/5.1/Ecma-262.pdf agrees with duplicate - "15.9.3.2 ... new Date() ... Parse v as a date, in exactly the same manner as for the parse method" and " 15.9.4.2 Date.parse (string) ...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 ... may fall back to any implementation-specific ... date formats. " – Alexei Levenkov Aug 29 '17 at 07:55
  • @Kira, if you believe that format accepted by `new Date` and `Date.parse` should be covered by different sections of the specification it may be easier to just provide your interpretation of the specification in your [edit] of the post so it can be re-opened. – Alexei Levenkov Aug 29 '17 at 07:56
  • @Kira—browsers only have one parser. Why would the Date constructor and Date.parse for a specific implementation use different parsers with different parsing rules? The entire implementation should comply with the standard, there's no exception for Date.parse. – RobG Aug 29 '17 at 08:36
  • @AlexeiLevenkov, a few months ago I started implementing with answers from marked questions and it was working in chrome I think. But now it is not working so I thought it might be a break or bug in chrome. I can write my own parsing to resolve this I wanted to know whether this is a bug in my side or not before moving to production – Kira Aug 29 '17 at 08:49
  • @Kira reality is if you need to defined behavior from officially *undefined behavior* you have to write your own code to do so. Writing DateTime parser that can reasonably handle dates (especially if you need to support more than one country) is hard (what day "1/2/3" stands for?). Forcing input into some particular format (preferably ISO8601) is better choice if such choice is available. – Alexei Levenkov Aug 29 '17 at 21:59

2 Answers2

1

I don't think it is a bug. When you call Date constructor with a string as an argument, that string parses via Date.parse.

And MDN says:

Parsing of strings with Date.parse is strongly discouraged due to browser differences and inconsistencies.

It also says:

However, invalid values in date strings not recognized as simplified ISO format as defined by ECMA-262 may or may not result in NaN, depending on the browser and values provided, e.g.:

It looks like current V8 (Chrome) parse implementation tries to guess, what was passed.

FYI:

Denis L
  • 3,209
  • 1
  • 25
  • 37
  • date never result as NaN – Manoj Pilania Aug 29 '17 at 05:53
  • 1
    @ManojPilania—the result of *Date.parse* will be NaN where the string is determined to be an invalid date. If an invalid date string (where "invalid" is entirely up to the parser) is used with the Date constructor, the internal time value will be NaN and *Date.prototype.toString* will return "Invalid date". – RobG Aug 29 '17 at 05:54
  • it looks like the crbug #126448 is partially fixed for strings like "FY2017", "a1". if there is a space between string and numeric part then it considers as valid date – Kira Aug 29 '17 at 05:58
  • @RobG ya you are right. – Manoj Pilania Aug 29 '17 at 05:58
1

Chrome is parsing only numbers in input string.

Example:

new Date('AS 2017') //Year part is parsed.
Sun Jan 01 2017 00:00:00 GMT+0300

new Date('XCNCNNC 2017') //Year part is parsed.
Sun Jan 01 2017 00:00:00 GMT+0300

new Date('FY2017') //without space. Year is not parsed.
Invalid Date
Manoj Pilania
  • 664
  • 1
  • 7
  • 18