我们再来看看第三个案例，它显示的就是[本地时间]的2016/09/24，这个小差别你必须特别注意，因为你打开网页的人不见的都位于台湾时区，因此显示的七日有可能不是2016/09/24，如果你的电脑时区设置在其他地区，也有可能会显示2016/09/23.

Safari 9.1.2（Mac OS X/EI Caption）

　　人们都说Safari就是另一个IE浏览器不是没有道理的，连特征都跟IE~11很像，可惜现在大部分ios9跑的也是safari9的版本

Safari 10 ( Mac OS X / Sierra )

　　接着我们再加上[时间]部分的字符串，看看各浏览器之间如何解析[日期时间]字符串格式的执行结果。

IE6~8

　　非常好，没有意外，不支持的日期格式还是不支持

IE9~11

　　差别又出现了，什么？2016-09-24 12:21:00 这种格式你也不接受，你在开玩笑吗？

Edge

　　微软的Edge浏览器在很多地方的支持度，却是比IE好很多了。

Chrome

　　我们加上时间之后，原来第一种案例与第三种案例，不再会相差8个小时了，而是通通解释为本地时间

Safari 9.1.2 ( Mac OS X / El Capitan )

　　哎，UCCU～safari是不是真的跟IE9～11很像！是不是～

Safari 10 ( Mac OS X / Sierra )

　　即便到了safari10最新版本，第一种格式不支持就是不支持，脾气很硬啊。

　　上面列了这几种日期格式，应该算是在台湾比较常见的日期格式吧。

　　如果深在台湾，一般人都不习惯用欧美习惯的日期表示法(9 September, 2016 12:21:00)来创建日期时间字符床，因为从上述测试的情况来看，这种格式反而是最没问题的。不过，开奖，也不是真的那么[没问题]，请各位想想，如果上网的人不在台湾，而你的日期时间代表的是[台湾时区]的时间，这时透过java解析出来的时间，就是错误的。因为浏览器预设会将这个日期格式的字符串解析为[用户目前浏览器的本地时间]，如果你又刚好降日期显示出来，那么时间就很有可能出现误差，除非你在页面上很明确地说这个时间就是台湾时区的时间。

　　我最常看到的日期格式应该是2016-09-24 12:@1:22这种，但你可以发现，从上述测试的案例来看，在IE6～8以及它的兄弟safari并不支持这种用法，这包含iPhone/iPad内置的safari版本，因此移动版网页遇到这种日期格式，通通完蛋。

　　真正万无一失的日期字符串格式

　　接着就要进入重点了，事实上在ECMA Language Specification - ECMA-262 Edition 5.1规范中，有对Date Time String Format 作出了非常明确的定义，意思就是说，要使用Date.parse()或new Date(dateString)来解析日期格式字符串，有一套标准的格式定义，规范中定义了要用简化版的 ISO 8601延伸的格式。

　　这个 ISO 8601 Extended Format格式大概是这样：

　　YYYY-MM-DDTHH:mm:ss.sssZ

　　一个实际的日期时间规范如下（以下是格林威治标准时区的时间）

　　2016-09-25T02:24:39.385Z

　　事实上，这种标准的日期格式，也可以允许只有日期部分，而且还不一定要写完整的日期格式，只有年份也可以当成合法有效的日期格式。

　　例如一下日期格式都是合法的、有效的跨浏览器、跨平台的日期字符串格式。

　　new Date(‘2016’);

　　new Date(‘2016-09’);

　　new Date(‘2016-09-25’);