date-fns: format returns "undefined NaN, 0NaN" for invalid dates

@umidbekkarimov @okonet

As I see it, if any argument is Invalid Date and the result should be Date, then function should return Invalid Date

I guess it should throw another TypeError because it’s in developer responsibility to check value before parsing it, silently formatting invalid values can create problems in UI

The point of my proposal is to mirror JavaScript arithmetic operations, with Invalid Date being a counterpart of NaN (since Invalid Date is a Date with value=NaN)

So:

parseInt('qwe') //=> NaN
dateFns.parse('qwe') //=> Invalid Date

NaN + 5 //=> NaN
dateFns.addYears(new Date(NaN), 5) //=> Invalid Date

I agree with exception being a result of format(new Date(NaN)) though

I like the idea of having Invalid Date in function that return Date and exception for format(new Date(NaN)). See the native Date behaviour:

Functions like getSeconds should always return NaN when the argument is an Invalid Date:

It’s works like that right now, but I want to be sure that this is applicable to all similar functions.

I made a research and to make date-fns consistent with Date we need to return NaN from the functions that return a number (e.g. getSeconds) and "Invalid Date" from the functions that return a string.

@LeshaKoss

@umidbekkarimov i thought parse returns always returned either Date or Invalid Date 🤔 So

You’re right, i made this changes as soon as i jumped to date-fns and isValid start throwing type errors everywhere in project 😅 so I double checked it everywhere (yes, I have trust issues)

But thanks, i will fix this part in my helpers.

As I see it, if any argument is Invalid Date and the result should be Date, then function should return Invalid Date

I guess it should throw another TypeError because it’s in developer responsibility to check value before parsing it, silently formatting invalid values can create problems in UI

@albertorestifo

I’d say still return Invalid Date. The user will then be able to clearly see the error.

I disagree with it, i think it’s in developer responsibility to handle unformattable values and libs should not silently return unexpected results

so if it throw an error you can handle it like that:

const tryFormatDate = (date, format, notSetValue) => {
  try {
    return format(date, format)
  } (e) {
    return notSetValue  
  }
}

Otherwise you should do things like I did in https://github.com/date-fns/date-fns/issues/304#issuecomment-265673346 example

Use isValid everywhere and return Invalid Date would reflect the same behaviour as Date, seems like a good idea to me.

It would certainly give me more clues about what’s going on that seeing undefined NaN, 0NaN somewhere in my app