起因
今天做一个需求，使用新的日历组件替换老的日历组件。老的日历组件 onchange事件给的值是时间对象，新的日历拿到的值是 YYYY-MM-DD。
这点事情看上去很轻松呀😉，直接转就好了
new Date(value)
换完了之后呢，为了避免出问题，当然接着往后看逻辑，发现这里有个当前日期不可选的逻辑。
刚好打着断点，发现我这时间不对，居然是早上8点中，如果现在是8点之前，那个判断就通过了（好家伙，直接避免一个bug）
const now = new Date();
let isValid = val > now
为什么是8点呢？按照之前的印象应该是 00:00:00才对
new Date('2021-12-20')
// Mon Dec 20 2021 08:00:00 GMT+0800 (中国标准时间)
寻找原因
有事先google，发现了一个和我一样的情况
那么为什么默认是8点呢？有没有觉得8这个数字很值得关注，我们所在的时区是东八区，如果以GMT标准0点来算的话，在那个时间点，这里就是8点啊。 那我就可以这样理解了，创建时间时，它默认时间确实是0点，但是是以GMT为基准的，所以将其转换成本地时间就是8点。而
/分割的字符串在创建时，则是以本地时区为基准。 那么为什么js会对不同分割的时间字符串进行不同处理呢？貌似是因为-分隔且具有前导0的日期字符串，会被解析成ISO格式的字符串，以GMT时区为基准，不过我也没看懂。
按照这位作者的的理论是GMT问题
我们来验证一下
var d = new Date()
var n = d.getTimezoneOffset();
// -480
果然输出的是 -480 ，12小时
我们再来试试逗号
new Date('2021,12,20')
// Mon Dec 20 2021 00:00:00 GMT+0800 (中国标准时间)
我们再来看一下 GMT和UTC的定义
GMT（Greenwich Mean Time）格林尼治时间 UTC（Coordinated Universal Time）协调世界时，又称世界统一时间、世界标准时间、国际协调时间。由于英文（CUT）和法文（TUC）的缩写不同，作为妥协，简称UTC。
这个日期连接符号-只能再找找文献了。
所以初始化时间 还是用 /更靠谱
如果用-也想达到 /的效果可以用
var d = new Date('2021-12-22');
d.setHours(0,0,0,0);
