Полезный 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, но, в целом, именно об этой связке я хотел рассказать.
    Метки:
    Поделиться публикацией
    Похожие публикации
    Комментарии 32
    • +11
      Вы забыли упомянуть одну важную деталь: Не нужно использовать это в реальных проектах :)

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

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


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

        • –4
          Вообще-то, никакое это не «магическое» поведение, это стандарт, причём старше чем сам Javascript. Браузеры ему строго следуют, и никогда не перестанут, так как иначе сломается обратная совместимость.

          Может быть, это неожиданное поведение лично для вас в силу невежества, но настоящий разработчик отличается от кодера тем, что исследует предметную область.
          • +4

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

            • +5

              Только в данном случае спеки как раз те же. Стандарт представления чисел, включая NaN, IEEE 754 появился в 1985, а объект Date очень нетипичен для JS и пришёл из Java. То есть это те особенности, которые были переняты из общепринятой практики. В восклицании «WTF JS» буквы «JS» лишние. Тут скорее в том, что приходит полные новички.

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

              20.3 Date Objects
              20.3.1 Overview of Date Objects and Definitions of Abstract Operations


              The following functions are abstract operations that operate on time values (defined in 20.3.1.1). Note that, in every case, if any argument to one of these functions is NaN, the result will be NaN.


              20.3.1.1 Time Values and Time Range


              A Date object contains a Number indicating a particular instant in time to within a millisecond. Such a Number is called a time value. A time value may also be NaN, indicating that the Date object does not represent a specific instant of time.

            • +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. То есть дата, но и в тоже время не дата.
                    • 0
                      Для такого случая можно подать просто пустую строку. Можно не добавлять сложности с NaN.
                      new Date('') // → Invalid Date
                      

                      P.S. С null всё логично, просто напросто isNaN(null) === false. Отличие null от undefined именно в том, что он приводится к нулю, когда идёт приведение к числу.
                      • 0
                        (new Date('')).valueOf() // NaN
                        • 0
                          Логично с точки зрения Number. Я прекрасно понимаю что вы имеете ввиду. Но вот с точки зрения даты — какая дата у никакого времени? Внутри конструктора Date можно было бы обойти такое «нативное» приведение типов. Из за этого приходится делать дополнительную проверку что то, что прилетело, это не null. Все остальное вернет правильный результат: либо Date либо Invalid Date.
                          • +1

                            null во многом неприятный объект, Крокфорд вон говорит, что вообще от него отказался.

                    • +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')

                        не работала
                        • +1

                          Вы здесь конвертируете переменную date в bool и проверяете её instance. Прочитайте про приоритеты операций. Правильно будет так:


                          if (!(date instanceof Date)) // ...
                          • 0

                            Тем не менее, это не поможет, так как объект Invalid Date из статьи — это всё равно Date. (Ранее на Хабре уже негодовали, что NaN — это Number).

                            • +1

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

                              • 0

                                Ну надо же похейтить ненавистный javascript :) А стандарт — да кому он нужен этот стандарт.

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

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

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

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

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