Полезный NaN

[Akuma]

Вы забыли упомянуть одну важную деталь: Не нужно использовать это в реальных проектах :)

Такое «магическое» поведение может зависеть от браузера, может поменяться внезапно в каком-то браузере или еще чего.

[xel]

да нет здесь никакой магии, конструктор принимает число, а NaN — число
приведение типов также работает предсказуемо и ожиданно
в исходниках momentjs используют подобную конструкцию

статья лишь напоминает, переходящим с php и других языков, с чуть другой логикой, что в javascript есть особые числа — Infinity, NaN и методы для работы с числами isFinite(), isNaN()

[Zenitchik]

Тяжела и неказиста жизнь JavaScript-ера… Каждый, не читавший спеку, думает, что он умнее, потому что "в большинстве языков" спека другая.

[ua9msn]

Это не магия. NaN в JS это данность, Date работает так как работает. Никаких изменений тут не будет. Даже в черновиках следующих версий JS ничего про дату нет, хотя очень очень хочется добавить установку произвольной таймзоны. Нет и не будет.

[Large]

Есть на stage 1 github.com/tc39/proposal-temporal

[Vovaka]

Как и упомянул выше ua9msn изменений поведения типа Date не предвидется. По указанной Вами ссылке говорится о исправлении API в его использовании за счёт введения в язык новых типов — CivilDate, CivilTime etc.
Или я что-то упустил?

[awMinor]

Все же я так и не понял полезность данной конструкции в реальной жизни и чем полезен NaN

[tenbits]

Например, проверить или распарсенная строка действительно была датой.

let date = new Date('foo');
let isInvalidDate= isNaN(date);
console.log(isInvalidDate ? "Yes, it was invalid" : "Ooops, was OK");

[torbasow]

Только NaN тут не при чём, на самом деле. Это функция isNaN выдаёт true на всё, что не приводится к числу, в частности, на строку «Invalid Date». А Number.isNaN(«Invalid Date»)===false.
Изложение в статье крайне сумбурное и запутывает простые вещи.

[Zenitchik]

isNaN использует метод valueOf, а он у Invalid Date возвращает NaN. Ни при чём как раз строка.

[sbnur]

Результат чтения — NaN

[Poccomaxa_zt]

Я задам возможно неправильный вопрос — но если Вы принимаете ко вниманию ситуации, когда Вам необходимо создавать даты с вероятно невалидными данными, возможно стоит все-таки изначально делать соответствующие проверки? Мне кажется это будет более правильная логика чем работать далее с Invalid Date…

[ua9msn]

Ситуация возникает когда необходимо иметь невалидную дату изначально.
Например для input field. Можно же ничего туда не вводить. Наилучшее представление для отсутствующей даты — Invalid Date. То есть дата, но и в тоже время не дата.

[ua9msn]

Логично с точки зрения Number. Я прекрасно понимаю что вы имеете ввиду. Но вот с точки зрения даты — какая дата у никакого времени? Внутри конструктора Date можно было бы обойти такое «нативное» приведение типов. Из за этого приходится делать дополнительную проверку что то, что прилетело, это не null. Все остальное вернет правильный результат: либо Date либо Invalid Date.

[dagen]

Интересное применение, не знал об этом :) Есть только один нюанс: в рамках ECMAScript 6 многие функции работы с числами, которые в предыдущих версиях были глобальными функциями, постепенно переезжают в статические методы Number. Чтобы в светлом будущем упорядочить хаос в JavaScript и пометить как устаревшие глобальные isNaN, parseInt, ...you name it.

Number.isNaN при этом не повторяет точь-в-точь поведение window.isNaN (в новой версии отсутствует неявное приведение типов), так что трюк из статьи не прокатит :( Но спасибо, всё равно интересно было почитать.

[ua9msn]

Там все немножко по другому. Да, есть свой isNaN в Number, но это тема для отдельной статьи.

[valis]

При этом, проверка на валидность даты становится проще некуда

Ну не знаю, для меня было потрясением когда конструкция типа

if (!date instanceof Date) throw new Error('Invalid Date')

не работала

[Zenitchik]

Хотя, не понятно почему. NaN по IEEE 754 — одно из предусмотренных значений числа с плавающей точкой.

[cinic]

А с чего ей работать? В данном случае нужно try...catch использовать.

[Zenitchik]

А зачем здесь try...catch? Ниже уже написали, что надо а) про приоритет операторов помнить, б) проверять на валидность, а не на соответствие типу (которая тут совсем ни при чём).

[cinic]

Блин, точно, тут не зачем.
Просто привык в проектах возвращать .toISOString() — оно для Invalid Date вывалит эксепшн, а тут и try...catch как раз в помощь.

[kemsky]

Не то что бы NaN был такой полезный, скорее в JS дату на валидность не проверить по-другому. Ну неявно еще можно вот так x.getTime() === x.getTime().