山维空间

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

前两天发现一个小程序的问题，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-01 和 2018-01-01T00:00:00 ISO 格式，Safari 也支持，但是会以格林威治时间为准，和我们有8小时的时差。Chrome 和 Android 内嵌的 WebView（基于 Blink 或者 Webkit）则都支持，所以在本地和 Android 手机上没有问题。

如果您觉得文章内容对您有用，不妨支持我创作更多有价值的分享：

在 GitHub 上赞助我

已发布

分类

来自

meathill

标签：

, , , , , ,

评论

《 “Safari 下 Date 不支持”2018-01-01 00:00:00“” 》 有 2 条评论

  1. Tom 的头像
    Tom

    做了一个小小的验证，检查这个字符串的内容：
    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. meathill 的头像
      meathill

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

      回复

回复 meathill 取消回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据。