7

If you take the following:

var s = "2/8888/2016";
var d = new Date(s);
alert(d);

In Chrome, you'll get:

Invalid Date

But in IE and Firefox, you'll get:

Fri Jun 01 2040 00:00:00 GMT-0500 (Central Daylight Time)

It appears to be just adding 8888 days to Feb 01. Instead, I would expect the date to be considered invalid. Is there a way I can make FireFox and IE think this date string is invalid?

lhan
  • 4,585
  • 11
  • 60
  • 105

3 Answers3

3

Short answer:

It's a misbehaviuor of the browsers you're mentioning.

You have to check date is in correct format on your own. But it's quite trivial, I suggest this approach:

Split the date in year y, month m, day d and create the Date object:

var date = new Date( y, m - 1, d ); // note that month is 0 based

Then compare the original values with the logical values obtained using the Date methods:

var isValid = date.getDate() == d &&
              date.getMonth() == m-1 &&
              date.getFullYear() == y;

Before doing all of this you may want to check if the date string is valid for any browser:

Detecting an "invalid date" Date instance in JavaScript

Long answer:

Firefox (and IE) accepting "2/8888/2016" as a correct string sate format seem to be a bug / misbehaviour.

In fact according to ECMAScript 2015 Language Specification when Date() is invoked with a single string argument should behave just as Date.parse()

http://www.ecma-international.org/ecma-262/6.0/#sec-date-value

The latter

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)

..that is specified here

http://www.ecma-international.org/ecma-262/6.0/#sec-date-time-string-format

where you can read

The format is as follows: YYYY-MM-DDTHH:mm:ss.sssZ

[...]

MM is the month of the year from 01 (January) to 12 (December).

DD is the day of the month from 01 to 31.

It seems that Firefox is interpreting the string value as when Date() is invoked with multiple arguments.

From

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date

Note: Where Date is called as a constructor with more than one argument, if values are greater than their logical range (e.g. 13 is provided as the month value or 70 for the minute value), the adjacent value will be adjusted. E.g. new Date(2013, 13, 1) is equivalent to new Date(2014, 1, 1), both create a date for 2014-02-01 (note that the month is 0-based). Similarly for other values: new Date(2013, 2, 1, 0, 70) is equivalent to new Date(2013, 2, 1, 1, 10) which both create a date for 2013-03-01T01:10:00.

This may explain how "2/8888/2016" turns into 2040-05-31T22:00:00.000Z

Community
  • 1
  • 1
Paolo
  • 15,233
  • 27
  • 70
  • 91
  • You have misinterpreted that MDN article. In this case, *Date* is being called with one string argument, therefore it is the rules for [*Date.parse*](http://www.ecma-international.org/ecma-262/6.0/#sec-date.parse) that are used: "*If Type(v) is String, then let tv be the result of parsing v as a date, in exactly the same manner as for the parse method…*". – RobG Jan 15 '16 at 04:33
  • "'*2/8888/2016' is a correct format for creating a Date object*" is at best misleading. It will cause implementation dependent behaviour (as the OP has discovered) and is not consistent with any format that is either specified in ECMA-262 or accepted by browsers in use. Nor is it a valid date string as 8888 is neither a valid month or day number. Therefore it is difficult to justify calling it "correct" in any context. – RobG Jan 15 '16 at 05:04
  • @RobG you're right. I almost rewrite my answer. Thank you for pointing me to the ECMA language specs. – Paolo Jan 15 '16 at 08:30
1

There's no way to make IE and FF think it's invalid, except:

  • you could change their javascript implementations
  • you use a library instead to deal with that.

We can also expect that Javascript, as a language, evolves and we can cross our fingers that browsers decide to follow a more strict specification. The problem of course is that every "fix" must be also backward compatible with previous versions of the language (does not happen always, Perl for example).

So the best thing by now is to use some library just like momentjs as suggested by Derek in the post comments.

Andriy Ivaneyko
  • 20,639
  • 6
  • 60
  • 82
Leo
  • 751
  • 4
  • 29
  • That's what I assumed, but wanted to check that there wasn't something obvious I was missing or could do. Thanks! – lhan Jan 13 '16 at 22:30
0

You have stumbled across yet another reason why you should manually parse date strings.

When Date is provided a single string argument, it is treated as a date string and parsed according to the rules in Date.parse. The rules there first attempt to parse it as an ISO 8601 format string. If that doesn't work, it may fall back to any parsing algorithm it wants.

In the case of "2/8888/2016", browsers will first attempt to parse it as an ISO format and fail. It seems from experimentation that IE and Firefox determine that the string is in month/day/year format and effectively call the Date constructor with:

new Date(2016,1,8888);

However, other browsers may attempt to validate the values and decide that 8888 is not a valid date or month, so return an invalid date. Both responses are compliant with ECMA-262.

The best advice is to always manually parse date strings (a library can help, but generally isn't necessary as a bespoke parse function with validation is 3 lines of code) then you can be certain of consistent results in any browser or host environment.

RobG
  • 142,382
  • 31
  • 172
  • 209