Полезный NaN

    О NaN больше всего известно то, что он не равен самому себе.

    NaN === NaN // false

    И что операции, невозможные арифметически, вернут NaN.

    'BlaBlaBla'/0 // NaN

    Но у NaN есть одно мало известное(?), и, как мне кажется, весьма полезное применение.

    TL;DR Все дело в Date


    В двух словах:

     new Date(NaN) // Invalid Date 

    Чем полезно? Invalid Date все равно Date. И все операции с Date все ещё на месте.
    Любые операции с Date, кроме прямой установки timestamp вернут NaN, оставив Date как Invalid Date.

     
    const x =  new Date(NaN) // Invalid Date 
    x.setTime(12345) // 12345
    x.toString() // "Thu Jan 01 1970 00:00:12 GMT+0000 (+00)"
    

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

     
    const x = new Date(NaN) // Invalid Date 
    isNaN(x) // true
    x.setTime(0)
    isNaN(x) // false
    

    Заметьте, преобразование в timestamp здесь не требуется, valueOf() делает это под капотом.

    Все операции с Date — мутабельные. Тем не менее, клонирование через конструктор прекрасно работает и с Invalid Date.

     
    const x =  new Date(NaN) // Invalid Date 
    const y = new Date(x) // Invalid Date
    

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

     
    const x =  new Date(NaN) // Invalid Date 
    const y = new Date(NaN) // Invalid Date
    x.getTime() === y.getTime() // false
    

    К моему сожалению, конструктор Date ведёт себя несколько странно по отношению к входному параметру.

     new Date(null) // Thu Jan 01 1970 00:00:00 GMT+0000 (+00) 

    Было бы намного логичнее конструировать Invalid Date, ведь null — это не совсем ноль. Оставим это на совести Javascript-а.

    Однако, если насильственно передать в конструктор undefined, то результат выглядит ожидаемым. Так что будьте осторожны.

     new Date(undefined) // Invalid Date 

    Статья получилась больше о Date чем о NaN, но, в целом, именно об этой связке я хотел рассказать.

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 32

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

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

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


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

        • UFO just landed and posted this here
            +4

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

            • UFO just landed and posted this here
            +3
            Это не магия. NaN в JS это данность, Date работает так как работает. Никаких изменений тут не будет. Даже в черновиках следующих версий JS ничего про дату нет, хотя очень очень хочется добавить установку произвольной таймзоны. Нет и не будет.
              –1
              Есть на stage 1 github.com/tc39/proposal-temporal
                0
                Как и упомянул выше ua9msn изменений поведения типа Date не предвидется. По указанной Вами ссылке говорится о исправлении API в его использовании за счёт введения в язык новых типов — CivilDate, CivilTime etc.
                Или я что-то упустил?
                • UFO just landed and posted this here
            • UFO just landed and posted this here
              +5
              Все же я так и не понял полезность данной конструкции в реальной жизни и чем полезен NaN
                +2

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


                let date = new Date('foo');
                let isInvalidDate= isNaN(date);
                console.log(isInvalidDate ? "Yes, it was invalid" : "Ooops, was OK");
                  0
                  Только NaN тут не при чём, на самом деле. Это функция isNaN выдаёт true на всё, что не приводится к числу, в частности, на строку «Invalid Date». А Number.isNaN(«Invalid Date»)===false.
                  Изложение в статье крайне сумбурное и запутывает простые вещи.
                    0

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

                0

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

                  +2
                  Я задам возможно неправильный вопрос — но если Вы принимаете ко вниманию ситуации, когда Вам необходимо создавать даты с вероятно невалидными данными, возможно стоит все-таки изначально делать соответствующие проверки? Мне кажется это будет более правильная логика чем работать далее с Invalid Date…
                    0
                    Ситуация возникает когда необходимо иметь невалидную дату изначально.
                    Например для input field. Можно же ничего туда не вводить. Наилучшее представление для отсутствующей даты — Invalid Date. То есть дата, но и в тоже время не дата.
                    • UFO just landed and posted this here
                      • UFO just landed and posted this here
                          0
                          Логично с точки зрения Number. Я прекрасно понимаю что вы имеете ввиду. Но вот с точки зрения даты — какая дата у никакого времени? Внутри конструктора Date можно было бы обойти такое «нативное» приведение типов. Из за этого приходится делать дополнительную проверку что то, что прилетело, это не null. Все остальное вернет правильный результат: либо Date либо Invalid Date.
                          • UFO just landed and posted this here
                      +4
                      Интересное применение, не знал об этом :) Есть только один нюанс: в рамках ECMAScript 6 многие функции работы с числами, которые в предыдущих версиях были глобальными функциями, постепенно переезжают в статические методы Number. Чтобы в светлом будущем упорядочить хаос в JavaScript и пометить как устаревшие глобальные isNaN, parseInt, ...you name it.

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

                        Ну не знаю, для меня было потрясением когда конструкция типа
                        if (!date instanceof Date) throw new Error('Invalid Date')

                        не работала
                        • UFO just landed and posted this here
                          • UFO just landed and posted this here
                              +1

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

                              • UFO just landed and posted this here
                            0
                            А с чего ей работать? В данном случае нужно try...catch использовать.
                              0

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

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

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

                            Only users with full accounts can post comments. Log in, please.