这个 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]

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

[millx]

@Cbdy 时间戳除了可读性不好，其他应该还是没问题的 😆

[Cbdy]

@millx 可读性是最严重的问题了，然后他是数字，“类型对不上”，还有诸如 2038 问题

[millx]

@Cbdy 也是，养成统一格式习惯可以省好多事儿

[doubleflower]

没碰到过，从来不用这种感觉不牢靠的方式

[millx]

@doubleflower 你用哪种？

[royzxq]

```js
function parseDate(date) {
if (!date) return new Date()
if (date instanceof Date) return date
if (!/[^\d]+/g.test(date)) {
date = date.toString().concat('000').substr(0, 13) * 1

return new Date(date)
}

return new Date(date.toString().replace(/-/g, '/').replace(/T|(?:\.\d+)?Z/g, ' '))
}
```

[millx]

@royzxq 👍 不错

[doubleflower]

@millx 我没用过中间有空格的，感觉不符标准

[kefengong]

把 - 换成 / 就可以了

[learnshare]

这不叫 Bug，是 Chrome 容错更强而已

2018-06-15 00:00:00 这不是标准格式
参考 https://zh.wikipedia.org/wiki/ISO_8601

[weixiangzhe]

不是 bug 这个是兼容问题，推荐 dayjs 吧，api 兼容 momentjs，大小只有 2kb，https://github.com/iamkun/dayjs

[millx]

@learnshare 是的

[millx]

@weixiangzhe 这个赞，可以 locale 收藏了

[wwt2017]

Safari 用 - 转化为毫秒时也会出问题

[auroraccc]

平常用个 dayjs 就行了 , momentjs 好大

[zpf124]

ie 也有这个问题

'2018-06-15' 正确
'2018/06/15 00:00:00' 正确

'2018-06-15 00:00:00' 报错。

[millx]

@auroraccc @royzxq 他的这个 parseDate 也不错

[millx]

@zpf124 应该都是老老实实按标准来实现的 哈哈哈

[mooo]

第一种不规范啊， 规范只支持 RFC2822 和 ISO 8601 标准的

[metrxqin]

**前端需要计算账号过期时间**

你确定这种设计足够安全?

[millx]

@metrxqin 前端后端都需要啊，为什么不安全？

[millx]

@metrxqin 前端只是用来计算显示的啦，后端肯定需要自己重新计算的，不要太紧张 😆

[Cynic222]

@wenzhoou #1 moment 太大，现在有个 dayjs，一样的 api

[ernest]

ISO 8601 date string 格式了解下：2018-06-15T00:00:00 是 js Core 支持的。https://en.wikipedia.org/wiki/ISO_8601

[Building]

js 没有 bug，如果有的话，那是 feature。

[iamkun]

@millx 其实这几个时间字符串都不是标准时间，所以呢不同浏览器的支持情况是不一样的。 推荐前后统一用 ISO 时间或者时间戳，省心省力

当然，欢迎体验 dayjs , 2kb 类似 moment.js 的时间库，欢迎提出各种改进意见。

[feder]

LS dayjs 作者

[wenzhoou]

恩。那我下次项目也用 dayjs

[millx]

@iamkun (*@ο@*) 哇～ dayjs 作者 😆

[scplay]

第一次用 dayjs 发现 dayjs 没有解决 iso8601 在 safari 上的问题，果断换回 moment，

[iamkun]

@scplay 请问在 safari 上是什么问题呢