Safari 下 Date 不支持”2018-01-01 00:00:00“

Chrome 可以支持非标准格式时间如 2018-01-01 00:00:00,safari 不支持,所以有时会导致错误。

前两天发现一个小程序的问题,Android 正常,iPhone 出错。我们都知道,Debug 的关键在定位,如果是某些特殊环节,不常见的错误,就会浪费很多时间。

这个 Bug 也是如此,反复拉锯之后终于发现,问题出在下面这句:

let a = new Date(`${date} 00:00:00`);

date 是服务器端返回的值,我是把它和后面的 00:00:00 连起来,记作某天零点零刻,和今天的零点零刻做减法,计算日期差,并按照日期差来决定接下来的逻辑。这段代码在开发工具(包括 Mac)、Android 手机上运行都正常,只有在 iPhone 上不正常,于是我打开 Safari——苹果这点做得不错,桌面版 Safari 环境和 iOS 几乎没有差别,该出的问题一定会出——果然复现了这个问题。

按照规范,中国的日期格式是:“2018/01/01”,Safari 只支持这个格式。而 2018-01-012018-01-01T00:00:00 ISO 格式,Safari 也支持,但是会以格林威治时间为准,和我们有8小时的时差。Chrome 和 Android 内嵌的 WebView(基于 Blink 或者 Webkit)则都支持,所以在本地和 Android 手机上没有问题。

作者: meathill

爱编程,爱旅游,爱吐槽。 今年的目标是完成并运营至少一个 Side Project。 《Electron + Vue 实战开发》龟速创作中……

《Safari 下 Date 不支持”2018-01-01 00:00:00“》有2个想法

  1. 做了一个小小的验证,检查这个字符串的内容:
    new Date(“2018-01-01T00:00:00”).toUTCString();
    在Node.js和Chrome下会输出”Sun, 31 Dec 2017 16:00:00 GMT”,
    而在Safari下输出”Mon, 01 Jan 2018 00:00:00 GMT”,
    这说明解析时间字符串时Node.js和Chrome默认当前时区,而Safari默认零时区。

    1. 是的,我姑且认为 Safari 在 localString 的格式之外,只接受 UTCString,并且是以标准时区也就是零时区。不去翻文档了,偷个懒。

欢迎吐槽,请勿装死