Be careful when falling back to Date constructor

[ichernev]

If you clicked on the warning link and landed here:

moment construction using a non-iso string is deprecated. What this means is you can safely do

> moment("2014-04-25T01:32:21.196Z");  // iso string, utc timezone
> moment("2014-04-25T01:32:21.196+0600");  // iso string with timezone
> moment("2014 04 25", "YYYY MM DD"); // string with format

but you can't do reliably (therefore its being deprecated)

> moment("2014/04/25");
> moment("Thu Apr 24 2014 12:32:21 GMT-0700 (PDT)");
> moment("some random string that looks like date");

In the upcoming releases a few more well defined formats might be added, but the general idea of using any random string to construct a date is no more. If you really want that behavior just do moment(new Date("random string that contains date")), but moment won't be responsible for such convertions. Read below for the rationale about the change

As described in #1403 (comment), but also recent debugging c4d9f6e and 94d6c90 caused by https://travis-ci.org/moment/moment/builds/16672288 brings me to the conclusion that

using Date to create a moment from string, passed from the user is extremely unpredictable, and it turns out to work somewhat and then bite you in an edge case when you're not careful

So I think we need an option to disable it, for tests at the very least. I've debugged that numerous times thank to our old friend IE6 and friends.

You'd pass a string only, hoping that it would hit one of the predefined formats, but instead it hits Date and it sort-of works, sometimes. I think it should be clear to users when they're hitting this case, and that it might not work well on all browsers.

The only use-case for using Date to parse input is when a) it is entered by a web user (moment's user's user :)) and b) the web user can see how we're interpreting the date entered. Every other case is just silently waiting to break at some point.

[icambron]

+1. I totally agree. We should start issuing a deprecation warning right away. Some additional support:

• That a string might go into the Date constructor or the ISO parser is ugly and confusing
• The most reliable way of using the Date string constructor was always new Date('2014-01-01'), which is now handled by the ISO parser anyway (i.e. moment('2014-01-01') doesn't use the Date constructor anyway).
• I'm pretty sure the constructor works differently in different locales for the same browser. E.g. new Date("05/06/2014") is May 6 in American browsers but June 5 in English browsers. So even if you test all your browsers, did you test all your locales? It's terrible for us to even pretend this stuff works.
• If you really want to use the date constructor, you can always just use the date constructor and pass the date into Moment.
• We could make moment(string) extensible, and then someone could create a plugin that either uses a list of well-known formats or just the Date constructor to parse them.
• If we remove the Date constructor fall-back, we can actually make the ISO parser less strict, since it won't be preempting a better parse. So that's a win too.

[ichernev]

The idea I liked most is for extensible constructor -- even if we disable Date parsing in moment, we should make it easy for people to migrate.

So lets do this:

moment.createFromInputFallback = function(config) { config._d = new Date(config._i); };

And call this method in the else clause of makeDateFromInput. In 3.0 we'll just remove this function, or place it under another name, so that one can just assign to the preset.

For tests right now, we can put a different function that throws an exception if called. I hope that would work just fine.

Inside we can print using console.warn (would go to stderr in node), only the first time it is called (like global deprecation) -- this is to let users know what awaits them.

[st3fan]

I don't understand this deprecation warning. I am using moment.js as documented, in an Angular.JS filter:

app.filter('scanDate', function() {
    return function(input) {
        var m = moment(input);
        return m.format("dddd, MMMM Do YYYY");
    };
});

Where input is an ISO formatted date string.

What do I need to do different to deal with this future deprecation?

If this deprecation warning is for the developers of this library and not for the users of it then I am going to suggest to remove it.

[icambron]

@st3fan Are you sure it's an ISO-formatted string? Moment is claiming that it isn't; it's saying that it can't parse it, and it is instead resorting to passing the string to new Date(s), which happens to work. That's the feature we're removing and are warning you about. In the future, it will fail. Your options are:

1. Ensure that the input really is ISO-8601 compliant (and file a bug if you think it is but are getting the warning anyway)
2. Parse the input explicitly using moment(input, string)

The warning is very much for you :)

[icambron]

This is implemented, so I'm closing it.

[Meekohi]

If we deprecate everything in Javascript that doesn't work on a side-case there will be no features left. ;) Looking forward to at least a few other "sane" date formats being added back in. Explicitly creating a Date or including the format string removes a lot of Moment's elegance.

[icambron]

@Meekohi We'll always allow ISO strings like '2013-05-10', which IMO everyone should just use. As for other strings, '05/10/2013' works differently in different locales, and most of the rest don't work across browsers. These aren't really side-cases; we receive an awful lot of support tickets here about surprises from things like moment("1.10.2014") where the user is expecting us to parse it consistently.

We are allowing this to be pluggable, so you can override the fallback parser (i.e. the thing currently giving a deprecation warning and then using the native parser) to do anything you'd like, and I suspect there will be some plugins built that do just that.