Date对象是JavaScript提供的日期和时间的操作接口，它有多种用法。手册上或者网上也有很多文章介绍，这里就不再次复述了。
上次遇到一个坑，这里总结下，也不是什么大问题，若是如果有经验，就不会花费很长时间去定位问题了。说下背景，一个早已经开发好的页面，在android的机器上运行的很正常，没出一点问题。某一天，产品狗跑来问我，为啥IOS上这个页面是空白的，为啥呢？到底是为啥呢？在需求忙不停的时候我还得抽空看这个外网bug，这哪算bug，要上IOS平台也没经过测试啊，什么时候被放到IOS的APP里面去了，简直不想吐槽。
在IOS APP里面debug的方法目前还没有找到合适的，借助mac机器可以做到类似chrome的remote debug功能，但也不是人人都有mac机器，屌丝开发只能借助alert了，不喜欢弹窗的可以document.write，将可疑之处全部输出，定位错误。最后发现是在new Date(''xxxx'')，这个对象上报错了。
后台同学给出的字段就是2010-11-29 11:11:11这种格式的日期，严谨点应该输出时间戳，这里就不再吐槽后台同学了，比较都是一条船上的。
IOS的浏览器不能解析2010-11-29，说到底就是浏览器实现的标准不同，这样也没什么好争论。在PC时代IE带来的蛋疼的问题还少么，只能踩一个坑填一个了，解决方案在代码里面。
alert(new Date('2010-11-29 11:11:11'))
alert(new Date('2010/11/29 11:11:11'))
dataStr.replace(/-/g, '/')
现在来看看一些其他的情况
/* safari invalid Date
PC chrome Mon Nov 29 2010 00:00:00 GMT+0800 (中国标准时间)
IE 7-9 Mon Nov 29 00:00:00 UTC+0800 2010
UC/QQ/weixin/QQ浏览器/android浏览器 Mon Nov 29 2010 00:00:00 GMT+0800 (CST)
*/
alert(new Date(
/* safari invalid Date
PC chrome invalid Date
IE 7-9 Fri May 11 00:00:00 UTC+0800 2012
UC/QQ/weixin/QQ浏览器/android浏览器 invalid Date
*/
alert(new Date(
/* safari invalid Date
PC chrome invalid Date
IE 7-9 NaN
UC/QQ/weixin/QQ浏览器/android浏览器 invalid Date
*/
alert(new Date(
/* safari Mon Nov 29 2010 00:00:00 GMT+0800 (CST)
PC chrome Mon Nov 29 2010 00:00:00 GMT+0800 (中国标准时间)
IE 7-9 Mon Nov 29 00:00:00 UTC+0800 2010
UC/QQ/weixin/QQ浏览器/android浏览器 Mon Nov 29 2010 00:00:00 GMT+0800 (CST)
safari 支持
*/
alert(new Date(
发现带/的时间格式都能支持，而带-的很多解析失败。注意下唯独IE能够解析new Date('11-29-2010')，关键解析出来的时间并不是你想要的。不过这种写法大家也不是很常用，最理想的方式还是时间戳，最后前端再格式化，这样才最妥。
看下格浏览器输出内容的意思
- CST：China Standard Time ，等同于chrome浏览器(中国标准时间)。
- GMT： Greenwich Mean Time，格林尼治标准时间
- UTC：Coordinated Universal Time，协调世界时，又称世界标准时间或世界协调时间。
大家都知道北京时区在时区划分上，属东八区，比协调世界时早8小时，记为UTC+8。当格林尼治时间为凌晨00:00时，中国标准时间刚好为上午08:00。
IE的是UTC+0800，其他的确实GMT+0800，那么这两者到底有什么区别？
UTC是经过平均太阳时、地轴运动修正的新时标以及以秒为单位的国际原子时所综合精算而成的，某种程度上来说是要比GMT更加精确，但其差值保持在0.9秒以内，所以差别也不会很大，就是各浏览器执行的标志不同。说了很多关于时间的东西，有兴趣的可以查阅更多资料学习。
回复 jesse 取消回复