这个 js bug 应该大家都碰到过吧？

[millx]

开发 bufpay.com 个人收款接口 的时候，前端需要计算账号过期时间。直接用了：

var t = new Date('2018-06-15 00:00:00');

这样来初始化，在 Chrome 里面是没问题的，但是 Safari 里面就不行了，发现 Safari 支持 ：

var t = new Date('2018-06-15');

和这样

var t = new Date('2018-06-15T00:00:00');

Chrome 里面是上面三种格式初始化都支持的。

这个 bug （应该也不能算 Safari 的 bug ）应该是 Chrome 做了兼容，Safari 是符合 ECMAScript IOS 8601 关于时间的格式定义的。

[wenzhoou]

改用 moment.js 怎么样

[hanpei]

t = new Date('2018/06/15 00:00:00')
safari 这样可以
以前也遇到过
替换-为 /

[millx]

@wenzhoou 需求比较简单，注意到这个问题手动处理一下就好啦，不太喜欢引入太多 lib 😆

[cccRaim]

我好像是 split(' ')分成日期和时间，然后再对日期 split('-')区分出年月日

[millx]

@hanpei 嗯，这样也可以，或者是把空格替换为 T

[opengps]

遇到过-有问题，但是没深入研究，于是一直后台返回 2018/06/15 00:00:00 格式给前台 new Date('')。
目前没发现问题

[Mutoo]

这种必须前端后统一使用 IOS 8601，或者使用 UTC Timestamp 整数，不然遇到不同时区的时候，就蛋疼了。
IOS 8601 的 T 部分是负责时区

[millx]

@opengps 后台 PHP 么？ Python 里面 str(datetime.now()) 直接就是 '2018-06-15 11:23:06.674947' 这种格式

[grewer]

以前碰到过,反正只要以'/'作为分割,那就没什么问题了

[Mutoo]

@Mutoo 更正一下，Z 部分负责时区（可选）

[zjsxwc]

moment.js +1

[millx]

@Mutoo timestamp 可读性不太好 /(ㄒoㄒ)/~~

[agagega]

同样的坑也出现在 iOS 平台的微信小程序里

[millx]

@agagega 就是不同 js 编译器有差异，容易被忽略

[jin5354]

原生 Date 兼容性问题多了，非 IOS 8601 标准格式，有的端直接报错，移动端某些版本还会出现 8 小时误差（不标 Z 的话有的按东八区算，有的按零时区算），如果跨端多非标准格式还是建议用个库

[zhouyg]

建议覆盖掉原生 Date 类型，改为自己实现或模块

[zenxds]

new Date(时间戳)
new Date('2014/07/12 12:34:35')
new Date(year, month, day[, hour[, minute[, second[, millisecond]]]])

其他的都有兼容问题

[millx]

@zenxds 统一用这几种就够了

[Cbdy]

不要用时间戳数字，不要用奇奇怪怪的格式，数据传输统一用字符串，用 ISO8601 格式！

[kslr]

用时间戳处理只有展示格式化可以避免很多奇怪的问题