javascript日期处理函数的一些问题
问题1:new Date(字符串)产生的日期对象,在某些情形下,可能会自动增加1天。猜测是和时区、UTC、GMT有关,浏览器没有默认当前时区?这是一个坑。
new Date(2022, 10, 30); //日期对象是 2022-10-30 new Date(2022, 10, 31); //日期对象是 2022-11-01
同样的道理,
var d = new Date(2022, 10, 30);//日期对象是 2022-10-30 d.setDate(d.getDate() + 1); //日期对象变成2022-11-01,而不是预料中的2022-10-31
感觉javascript中setDate函数的实现方式貌似借道new Date()函数,直接把天数加1后产生新对象并把指针指向原来的日期对象。
Date对象相关函数处理和程序员想象中的处理方式不同,是否有点反人类?
https://stackoverflow.com/questions/2488313/javascripts-getdate-returns-wrong-date
第二个高赞答案说是使用UTC可以解决这个问题,but……事实证明javascript的实现者有点……2B
new Date(2022, 10, 30, 0, 0, 0); //日期对象是 2022-10-30 UTC 08:00 new Date(2022, 10, 31, 0, 0, 0); //日期对象是 2022-11-01 UTC 08:00,而不是预料中的2022-10-31 UTC 08:00 new Date(2022, 10, 30, 16, 0, 0); //日期对象是 2022-11-01 UTC 00:00!
特别是new Date(2022, 10, 30, 16, 0, 0); 这句,直接得到2022年11月1日,感觉javascript认为10月30日后次日就是11月1日,压根忘记还有10月31日这天……
所以,这不是UTC和GMT能解释的,也不是不同浏览器之间的差异,同个浏览器也会出现这种诡异的事情。
那么最终怎么解决才是最稳妥的?难不成每个程序员自己实现一遍?
https://segmentfault.com/a/1190000022403847 这篇文章给出了解决方案,也指出了根本原因在于日期格式,比如:
'2020-4-20'
格式在各个浏览器都有不同的解析方式,所以可以转换成 '2020/4/20'
格式来解决解析不一致问题,如下:
function getDate (dateStr) { dateStr = dateStr.replace(/-/g, '/') return new Date(dateStr) }
经测试,上面2022-11-01能够准确得出结果。因此,不能说不推荐用Date构造函数来解析日期字符串,或者使用其等价的Date.parse,包括setDate都是,不能用,否则系统抽风还很难发现问题所在。