javascript - 如何处理双夏令时浏览器兼容性问题

Question

我遇到的问题是，Chrome 和 IE/Edge 将某些 JavaScript 日期时间序列化为 JSON 会给出不同的结果 - 例如英国 1945 年的夏天。

我有一个 JavaScript 对象，其中包含通过日历组件设置的日期类型，该组件将时间设置为本地时间午夜。该对象通过 JSON.stringify 序列化，而 JSON.stringify 又使用 Date.toJSON，而 Date.toJSON 又使用 Date.toISOString。

如果我的英国区域设置中的本地日期时间为 1977 年 5 月 1 日，则序列化为“1977-04-30T23:00:00.000Z”，即 UTC 1977 年 4 月 30 日晚上 11 点。没问题，但是如果我从本地 1945 年 5 月 1 日开始，我最终会使用 Chrome 与 IE/Edge 得到不同的结果。 Chrome 正确地为我提供了“1945-04-30T22:00:00.000Z”。之所以是晚上 10 点而不是晚上 11 点，是因为英国在二战期间实行双夏令时。

然而，IE/Edge 减去一小时意味着 JSON UTC 日期时间字符串超出一小时。

这对我来说意味着我不能信任传回服务器的 JSON 序列化数据，除非我知道它来自哪个浏览器。

我正在考虑重写 Data.prototype.toJSON 将序列化更改为基于本地时间的序列化，但包括时区偏移量，例如“1945-05-01T00:00:00.000+0200”。至少我知道用户的真正意图是什么。然而，这似乎有点极端，想知道我是否错过了一些东西。 JSON.stringify 是序列化要发送到服务器的数据的常用方法，但整个机制似乎有缺陷。

Answer 1

事实上，历史时区信息根据实现的不同而有很大差异。您在不同的浏览器中看到不同的结果，因为 Windows 不跟踪英国的历史更改。 IE 和经典 Edge(不是 Chromium 版本)使用 Windows 时区数据进行这些转换。 Chrome 提供了正确的结果，因为它附带了来自 IANA time zone database 的自己的时区数据。 (通过ICU)。

对于您描述的场景，用户从选择器中选择日期(大概是出生日期或类似的日期)，处理此问题的最佳方法是不。而不是使用 Date对象(实际上不是一个日期，而是一个时间戳)，保留用户选择的原始年、月和日。您可以为每个值保留单独的值，或者您自己创建的对象或数组，或者更常见的是，您可以保留 ISO 8601 格式的仅日期字符串，例如 "1945-04-30" .

确实，如果您使用 <input type="date"/> HTML5 元素，其 value将是该格式的字符串而不是 Date目的。还有其他日期选择器将返回该字符串，但如果您坚持使用返回 Date 的日期选择器。对象，然后只需从 .getFullYear() 的结果构造您自己的字符串, .getMonth() ，和.getDate() (适当填充零)。

然后，您可以在 JSON 结果中传递该字符串，而不必担心任何一方与 UTC 之间的任何转换，也不必担心历史时区数据是否存在。

作为替代方案，如果您无法使用 Date对象，那么某些人使用的一种方法是在序列化之前将时间显式设置为中午时间(例如中午 12 点)。即使时间转换为 UTC 或从 UTC 转换，这也会使年月和日部分保持在相同的原始日历日期上。