JS new Date在iOS下兼容性问题,网上99%的答案都是错误的

如果你不喜欢广告,请收藏我的网站,下次在网站中搜索
用真金白银赞赏有价值的内容,请通过文末二维码打赏

过去这些年我们对这个问题的重视程度几乎为0,以至于我们现在的所有有关时间的值的存储、使用,都可能是错的,这不是危言耸听,我们很多系统很可能都面临着问题。这个问题在很多情况下都没有暴露,直到我们把应用运行在iOS较低的版本的微信浏览器,或者较低版本的firefox等浏览器时,我们突然发现,竟然要解决这个问题,并且牵一发而动全身,甚至要后端配合一起重构有关时间值在数据库中的存储格式。没错,这就是有关我们开发中的“日期时间”问题。本文将详解为什么我们会遇到这样的问题,以及应该如何解决。

问题的暴露

当我们去面试的时候,总会遇到一些看上去傻叉,在实际中几乎不会遇到的问题,例如下面这道题:

请写出下面这几个表达式的结果:
new Date();
new Date(undefined);
new Date(null);
new Date('2021-01-01 12:00:00');
new Date(['2021-01-01', '12:00']);
new Date("December 17, 1995 03:24:00");
new Date('-278239-05-01');

怎么样,即使久经沙场的你,可能也会摸摸头这都是啥啥啥?有时候,我们感觉是对的,但其实是错的,就以我们最熟悉的第4行(标红)来说,大部份情况下我们都会觉得这一行没有任何问题,就是和我们预期的一样,也是我们工作中常用的方式,后端也是这样存储的。然而,当我们把这句话放到低版本的iOS中时,它返回的却是“Invalid Date”。正是这个错误,才有了今天这篇文章。

反思

长久以来,我们都和后端有一定的默契,后端返回mysql等数据库中存的日期时间字符串,由前端实例化为需要的格式来在界面中展示。然而,我们今天发现,mysql的datetime类型的默认返回结果,是错误的(不精确的),是不可以直接使用的,而把问题的根源再往前推,可能当我们的系统在用户选择一个日期,进行保存的那一刻,就已经出了问题。因为这些场景下,我们都没有考虑时区问题,对于拥有全球不同时区的用户的系统而言,两个用户选中了相同的日期,并提交保存,然而,这两个日期可能代表的实际意义是不同的,可我们在存储时却没有加以区分,最终导致在应用运行时使用该时间带来了逻辑上的错误。

如果对时区不加以考虑,那么用户就可以通过编辑系统时区,来实现绕过一些业务策略,从而给应用带来风险。因此,采取一定的策略,对于应用系统的安全是必要的。策略有很多,例如后端一律存储和输出timestamp,即UNIX epoch,由于对于电子钟而言,该值是固定的,即使时区不同,同一时刻的值也相同,因此可以避免一些问题,前端在拿到该值后在new Date来获得本地时间,把本地时间作为用户的运行时间。

策略虽多,但是对于前端的同学而言,必须反思,是否是因为我们的一些基础知识不牢固,才导致这样的问题没有被提前规避掉呢?

很多情况下,我们会按照自己的模糊经验来进行 new Date 得到一个时间对象,然而,你真的知道 new Date 的用法吗?你确定你传入的参数是正确的吗?你确定你传入的参数,能够按预期返回结果吗?你确定你能够设计出你期望结果的参数吗?这些问题即使在面试时被忽略,但在实际工作中遇到时,你再来查资料,也不一定能解决,就像上面我遇到的问题,“new Date在iOS下的兼容性问题”,在百度搜索可以得到无数篇文章,里面清一色的告诉你,把 '2021-01-01 12:00:00' 替换为 '2021/01/01 12:00:00' 就能解决问题,真的吗?你确定吗?我可以告诉你,这种解决方案是错误的,如果这些文章被GPT作为训练语料,那么你在ChatGPT获得的结果也会是错误的。如此可悲的现象,令人担心。

从标准中寻找答案

要解决这个问题,我们必须寻求标准或者权威的参考。其中,标准应该阅读TC39的相关标准文档,权威资料可以参考MDN,虽然MDN绝大部分都是正确的,但是是不全面的,最终我们还是要看TC39的文档才能彻底解决我们的问题。TC39的标准文件没有告诉我们原理,我们不知道浏览器底层C/C++代码是怎么写的,以至于带来了问题,但是,TC39标准文件告诉我们按照如何去使用就一定是正确的。明明有标准文件可以参考,但是网络上的各种“我推测”“经过测试……”“有可能……”反复被转载,令人唏嘘。

我们来看下 new Date 参数的标准表现:

具体标准阅读TC39标准文件,我这里为了方便理解,用通俗的语言进行了解释。

从上图可以看出,不同的参数,带来的结果完全不同,接下来,我们用上面这张图,来反观一些案例,看看为什么它的结果和我们预期的不同。

new Date(undefined)

有1个参数,该参数类型为“其他”,尝试转化为number,得到NaN,chrome中尝试转化为string,无效,因此结果为Invalid Date。注意,new Date(undefined) 和 new Date() 是完全不同的,它们参数个数不同。

new Date(null)

有1个参数,该参数类型为“其他”,尝试转化为number,得到0,因此结果为1970-01-01T00:00:00.000Z.

new Date(["2020-06-19", "17:13"])

有1个参数,该参数类型为“其他”,尝试转化为number,得到NaN,chrome中尝试转化为string,再执行实例化 new Date('2020-06-19,17:13'),在chrome中该string符合某local time string格式,返回对应日期对象,在其他浏览器中返回Invalid Date。

new Date('2022-01-22 12:00')

有1个参数,该参数为string,用Date.parse进行解析,chrome中符合某local time string格式,可以被解析为对应时间戳number,以该number作为参数再执行实例化,最终可以得到一个日期对象。在iOS或部分safari中,用Date.parse无法解析得到一个时间戳number,最终返回Invalid Date。

由以上例子可见,new Date传参对结果的影响很大,且由于不同浏览器在实现本地化时间格式时各不相同,导致同参Data.parse返回结果不同,以至于出现了兼容性问题。至此,我们终于理解了标题中iOS时间格式不兼容问题的根源。而网上99%的文章中提供的将-替换为/的方法,只不过是把一个非标的时间格式替换为另外一个非标的时间格式,在不同的浏览器实现中Date.parse不一定最终按照预期的方式得到结果,因此实际上还是一个错误的解决方法。

正确的答案

通过上述分析之后,我们可以得到能够准确实例化时间的,通过后端存储的格式,只有两种:

  • UNIX epoch
  • ISO 8601标准字符串格式

虽然多个参数的形式也能准确实例化,但是由于考虑到后端存储和传输的便利性差,因此不在考虑范围内。

另外需要注意的是ISO 8601标准格式中,时区部分必须用:作为分隔符,这在TC39文件中有明确规定。因此类似 2024-01-02T12:00:00+0800 这样的时间格式看似正确,实际上是不被标准支持的格式。而这种近似标准的格式比非标格式更惨烈,在iOS中全军覆没。

新的Temporal标准

为了解决Date的缺陷,TC39邀请了moment.js的作者Maggie重新起草了一份新标准,即Temproal标准,该标准以解决原有Date标准的问题,同时提供了现代时间/日历需求的覆盖。你可以通过这里了解Temporal相关的内容。现在已经有了对应的polyfill来使用Temporal,不妨试试看。

结语

本文由一个日期实例化在iOS中的兼容性问题出发,详细阐述了Date实例化参数的标准,并且解释了非标准日期时间格式是引起兼容性问题的根源。或许我们都错怪了iOS中的实现,并非苹果作祟,而是我们提供了非标准格式的日期时间字符串惹的锅,而恰巧chrome在这个点上“多管闲事”比safari多实现了一些非标格式,才导致了iOS的兼容性问题。

2024-02-28 362

为价值买单,打赏一杯咖啡

本文价值3.62RMB