YYYY-MM-DD ios不能解析
我正在做一个webapp,需要跨平台,选用了cordova框架,今天在写订单管理根据时间搜索的时候,遇到一个大坑… …
订单管理需要根据时间搜索,我做了一系列date format的封装,由于后台需要YYYY-MM-DD
的时间格式,所以我在页面上的时间全部转成这种格式的,包括用时间计算,也是用的这样格式,我调试用的是chrome浏览器,我生成date对象是用的如下方法:
1 | var date = new Date("2016-09-30"); |
这种方法在chrome上运行正常,但是拿到Ios上的时候,就有问题了,这个方法会报invalid date
的错误,所以导致了我后续的一系列方法全部不能正常执行。我发现Ios上 2016/09/30
是可以的,包括 2016-09-30T22:27:07.08
这样也是可以的。
时区的问题
上午还正常的,临近下班测试的时候发现日期有一个Bug。因为今天是2016.9.30,在下午的时候,传一个时间进来,比如2016-09-30T22:27:07.08
,使用new Date(2016-09-30T22:27:07.08)
生成一个时间对象,接着看浏览器里的效果:
再看date的值,竟然变成了10月1号,不过仿佛时间增加了8个小时… 不过好在自己高中地理课没有睡觉,这明显是中国时间是东8区,存在一个格林威治时间,东8区比格林威治时间要早8个小时。那我这里需要的结果是,不管你传进来的是几点几分几秒,我需要展现的还是几点几分几秒,不允许时间快8个小时,所以我在new date()之后,操作时间的话,必须要在new date()的时候,立马减去这8小时的时差.
1 | var time = '2016-09-30T22:27:07.08'; |
上面的一段代码可以返回 YYYY-MM-DD
格式的时间,需要注意,month从的范围是0-11,另外还有个小技巧,
在进行时间计算的时候,如果增加或减少天数,增加或减少之后需要夸月了,只要dateObj.setDate(xxx),最后生成的date会自动调整成为一个正确的日期值,月份计算的时候也是同理
总结
时间的format真是一项非常耗时的工作,后面我会把一些常用格式时间的format,总结一个库出来方便以后复用