Does this PR introduce a breaking change?
Possibly. If a user of the date filter expects it to throw the DateRange error if a NaN value is passed.

LOL - That is hardly a problem. The real problem is for people not using Safari and expecting a Date object (with the appropriate methods) to be return for NaN, because now they will get a TypeError:

var value = NaN;   // some numeric value that can also be NaN

var date = dateFilter(value);
if (date.getTime() > someThreshold) {
  // Do this and that...
}

Before this change, the above snippet will work (date.getTime() will return NaN).
After this change, the above snppet will throw a TypeError (because date will be NaN and doesn't have a getTime() method).

Tbh, I don't think the benefits of this justify the cost.

The benefits are that we work-around one specific case (among several) of a bug in one specific browser.
The cost is that we introduce a small breaking change.

I don't think many apps will be affected by this, but people upgrading will nevertheless have to go through the whole codebase checking for situations where a value passed to dateFilter could be NaN.

I don't feel too strongly though. Let's see what others think.

A agree with @gkalpak