Repository: iamkun/dayjs (JavaScript)

Issue:
Format need to check date is invalid & Don't format dayjs(null)
```js
const dayjs = require('dayjs');
const moment = require('moment');

console.log('\n=== dayjs ===');
console.log(dayjs('wtf').format());
console.log(dayjs(null).format());

console.log('\n=== moment ===');
console.log(moment('wtf').format());
console.log(moment(null).format());
```

That code will print: 
```
=== dayjs ===
NaN-NaN-NaNTNaN:NaN:NaN++N:00
2018-04-27T10:38:31+08:00

=== moment ===
Deprecation warning: value provided is not in a recognized RFC2822 or ISO format. moment construction falls back to js Date(), which is not reliable across all browsers and versions. Non RFC2822/ISO date formats are discouraged and will be removed in an upcoming major
 release. Please refer to http://momentjs.com/guides/#/warnings/js-date/ for more info.
Arguments:
[0] _isAMomentObject: true, _isUTC: false, _useUTC: false, _l: undefined, _i: wtf, _f: undefined, _strict: undefined, _locale: [object Object]
Error
    at Function.createFromInputFallback (/Users/ahonn/Desktop/test/node_modules/moment/moment.js:320:98)
    at configFromString (/Users/ahonn/Desktop/test/node_modules/moment/moment.js:2368:15)
    at configFromInput (/Users/ahonn/Desktop/test/node_modules/moment/moment.js:2594:13)
    at prepareConfig (/Users/ahonn/Desktop/test/node_modules/moment/moment.js:2577:13)
    at createFromConfig (/Users/ahonn/Desktop/test/node_modules/moment/moment.js:2544:44)
    at createLocalOrUTC (/Users/ahonn/Desktop/test/node_modules/moment/moment.js:2631:16)
    at createLocal (/Users/ahonn/Desktop/test/node_modules/moment/moment.js:2635:16)
    at hooks (/Users/ahonn/Desktop/test/node_modules/moment/moment.js:12:29)
    at Object.<anonymous> (/Users/ahonn/Desktop/test/index.js:16:13)
    at Module._compile (module.js:652:30)
Invalid date
Invalid date
```

You need to check date is invalid, `dayjs('wtf')` preferably returns `Invalid date`.
And `dayjs(null)` should not return current date, `null` is not equal to `undefined`.



Discussion:
After checking ECMAScript docs, I found a interesting thing.
```
new Date(null) // Valid
new Date(0) // Valid
// but:
new Date(undefined) // Invalid
new Date('wtf') // Invalid
```
That is to say, null is considered as a valid date in JS.

Still, I think `null` is different to `0`, and `null` should be an __invalid__ date.

Please share your thoughts.
`dayjs(null)`  should be an invalid date, but dayjs show the current date for now.
So what's wrong with this issue?
I agree. see pr #76 .

Just little weird that JS treat null as valid.
See https://www.ecma-international.org/ecma-262/6.0/#sec-date-value
`null` will be `toNumber(null)` when `new Date(null)`. So, `new Date(null)` is equal to `new Date(0)`.
Also, you can see https://github.com/moment/moment/issues/3415
:tada: This issue has been resolved in version 1.5.16 :tada:

The release is available on:
- [npm package (@latest dist-tag)](https://www.npmjs.com/package/dayjs)
- [GitHub release](https://github.com/xx45/dayjs/releases/tag/v1.5.16)

Your **[semantic-release](https://github.com/semantic-release/semantic-release)** bot :package::rocket:
@iamkun Revisiting this since we just migrated some code from moment to dayjs. I understand all of the reasoning here but it's an unpleasant experience to have code like `dayjs(foo).toISOString()` blow up if `foo` is `null`. Moment simply outputs `null` in this case. Can a simple validity check be added [here](https://github.com/iamkun/dayjs/blob/8e6d11d053393d97bee1ba411adb2d82de1a58c4/src/index.js#L370) (and maybe [here](https://github.com/iamkun/dayjs/blob/27d1c506100ae6624f258c21cc06b24768ced733/src/plugin/utc/index.js#L126)?). Something like `return this.isValid() ? this.toDate().toISOString() : null`
Was just surprised by this, too. Why does dayjs acceppt `null` as type in typescript only to be an invalid date then. From typescript point of view, this doesn't make any sense since an invalid date cannot be inferred as type further.
yep, came looking to say the exact same thing, its sometimes not easy to remember if a certain field in the database, or other place, is nullable. So you just stick it into dayjs() only to be met with a "Invalid date" text all over the app. Personally would prefer if TS would yell at me and force me to handle the case where it is null so I can conditionally render something else. What is the reason for allowing null? seems like its just there to be a default value in case it is null, but feels strange dayjs would take that responsibility, when would you ever want to just display "Invalid date" - usually comes with some custom logic or ui in user land.



Patch:
diff --git a/src/index.js b/src/index.js
index 7ad19fad2..7affa875d 100644
--- a/src/index.js
+++ b/src/index.js
@@ -3,6 +3,7 @@ import * as Utils from './utils'
 
 const parseConfig = (config) => {
   let reg
+  if (config === null) return new Date(NaN) // Treat null as an invalid date
   if (!config) return new Date()
   if (config instanceof Date) return config
   // eslint-disable-next-line no-cond-assign


Test patch:
diff --git a/test/parse.test.js b/test/parse.test.js
index 24ea5862f..69b5ea1f2 100644
--- a/test/parse.test.js
+++ b/test/parse.test.js
@@ -27,11 +27,12 @@ describe('Parse', () => {
     expect(dayjs(time).valueOf()).toBe(moment(time).valueOf())
   })
 
-  it('String Other and isValid', () => {
+  it('String Other, Null and isValid', () => {
     global.console.warn = jest.genMockFunction()// moment.js otherString will throw warn
     expect(dayjs('otherString').toString().toLowerCase()).toBe(moment('otherString').toString().toLowerCase())
     expect(dayjs().isValid()).toBe(true)
     expect(dayjs('otherString').isValid()).toBe(false)
+    expect(dayjs(null).toString().toLowerCase()).toBe(moment(null).toString().toLowerCase())
   })
 })