头图

考虑时区了吗?

前端工程师们,在拿到一个日期/时间数据的时候,你是怎么处理的呢?有没有考虑时区的问题呢?

也许你会说:嗯,没怎么关注时区,不过我测过,没问题。

我能怎么说呢?可能你还没遇到国外的用户吧!

被偷走的一天

如果拿到一个日期字符串 "2021-11-17",为了方便计算和处理数据,可能会先把它封成一个 Date 对象:

const s = "2021-11-17";
const d = new Date(s);

现在使用 d.getDate() 看会得到什么?—— 是 17,没毛病!

其实 —— 怎么说呢 —— 这是因为你在中国。如果这段程序在浏览器运行,而浏览器正好位于加拿大,还会是 17 吗?不妨试试。

在 Windows 下进入时间设置,把时间改为“太平洋时间(美国和加拿大)”或者其他 UTC-XX:00 的时区。再到浏览器里去看看,会发现 d.getDate() 得到了 16

如果是在 Linux 下,也可以重新设置系统时间,然后用 Node 控制台来查看,如下图:

Snipaste_2021-11-17_20-32-01.png

为什么少了一天?

浏览器始终使用本地时间

要问为什么少一天,不妨看看 d 到底是个什么样的数据(记得先把时区改回来哦!)

d.toString();         // Wed Nov 17 2021 08:00:00 GMT+0800 (中国标准时间)
d.toLocaleString();   // 2021/11/17 上午8:00:00

你看,new Date("2021-11-17") 创建日期对象的时候,是把 2021-11-17 当作 UTC 00:00:00 来创建的对象。而这个时间在中国 ,就是 2021-11-17 08:00:00。同理,如果是在 -06:00 的加拿大中部,它会是 2021-11-16 18:00:00,这时候 .getDate(),当然会得到 16

在处理时间这个问题上,浏览器处理得简单粗暴,就是根据系统的时区设置来按照本地时间进行处理。如果我们给的是一个精确的时间,浏览器这样处理没毛病。毕竟时间是世界的,在这个时间点上,中国是早晨,加拿大是黄昏 —— 问题在于,Date 对象不能只描述日期,还要描述时间,它自动按 UTC 补了时间数据之后,我们就可能得到非预期的结果。

带时间部分的字符串

那么,如果拿到的表示时间的字符串带时间的呢?是不是会准确一点 …… 试试吧:

// 为了方便查看,注释里的结果数据采用了简洁的描述
new Date("2021-11-17");           // 2021-11-17 08:00 +08:00
new Date("2021-11-17 00:00:00");  // 2021-11-17 00:00 +08:00
new Date("2021-11-17 09:00:00");  // 2021-11-17 09:00 +08:000

注意第 2 条。在我们的常识中,2021-11-17 00:00:002021-11-17 应该是同一个时间吧?后者不带时间部分,所以默认它是一天的开始,也就是 00:00:00 —— 问题就在这里,Date 对象默认它是 UTC 的 0 时,而不是本地时间的 0 时。但如果给了时间,Date 会把它按本地时间来处理 —— 莫名其妙地就出现了时差。

该如何做到无差别

因为 new Date() 的时候是按本地时间来解析的,所以在不同地区的浏览器里,同一个表示日期时间的字符串会被解析成不同的时间 —— 你看,中国的早晨 9 点和加拿大的早晨 9 点绝对不是同一个时间对吧!

如果我们希望 new Date() 拿到的是同一个时间怎么办?

说起来也挺简单的,只要拿到字符串包含时区信息就行了,比如符合 RFC3339 标准的时间表示 2021-11-17T09:00:00+08:00。RFC3339 这里就不详述了,只需要简单地理解为

  • 日期部分是 yyyy-MM-dd 格式
  • 时间部分是 HH:mm:ssHH:mm:ss.sss 格式
  • 日期和时间之间使用 T 连接
  • 时区部分是 Z 或者 ±HH:mm 格式,其中 Z 表示无时差,即 UTC 时间。比如下面两个时间是在同一个时间点上

    2021-11-17T09:00:00+08:00

    2021-11-17T01:00:00Z

很幸运 Date 能识别符合 RFC3339 标准的时间描述,所以用上例两个字符串创建的时间是相同的

const d1 = new Date("2021-11-17T09:00:00+08:00");
const d2 = new Date("2021-11-17T01:00:00Z");
console.log(d1.getTime() === d2.getTime());

还要注意什么

道理已经讲明白了,但是实际操作中还是会出现一些奇奇怪怪的问题。而出现这些问题的原因,归根结底还是没在注意到“时区”。比如,我问几个问题,看能不能搞得明白?

  • 拿到简单表示日期/时间的字符串,不符合 RFC3339 标准,比如前面提到的 "2021-11-17 09:00:00"。请问他是 UTC 时间还是本地时间?
  • 如果是本地时间 —— 它是应用服务器的本地时间?还是数据库服务器的本地时间?还是录入时间的用户所在时区的本地时间……?

你看,简单的一个时区问题,并不只是前端单方面的问题,它可能是整个系统设计的时候就因为忽略了时区概念而造成的问题。

如果在系统设计的时候就把时区问题考虑进去,所有存储和传输都使用相同时区的时间描述,事件就会变得好办得多。当然,如果直接使用 UTC 时间,或者 Unix Time Stamp 之类精确的描述会更理想。

也许有人觉得,浏览器确实只支持本地时间,但是我们可以用 Moment.js 库,可以用 Day.js 库,可以用 date-fns 库 …… 是的,你可以用各种各样的工具,但是还是得搞明白拿到的时间描述是准确无歧义的。再强调一次,准确的时间描述有:

  • 带时间信息的字符串,比如符合 RFC3339 标准的字符串描述;
  • 基于某个特定时间的秒级、毫秒级或更细微级别的时间偏移值,比如 Unix Time Stamp。

我们的程序生在中国,但要面向世界 —— 你考虑时区了吗?


边城客栈
全栈技术专栏,公众号「边城客栈」,[链接]

一路从后端走来,终于走在了前端!

56.2k 声望
26.5k 粉丝
0 条评论
推荐阅读
2022,二着二着又混过一年
收到思否小姐姐的活动提醒,才发觉又到了年底,该写“总结”了。说起总结,总有些倦——每天工作要写日报、项目上要写周报、月底要写月报、季度还有季总结,当然还有半年总结和年终总结……一年大约是 250 个工作日、50...

边城6阅读 787评论 2

封面图
从零搭建 Node.js 企业级 Web 服务器(零):静态服务
过去 5 年,我前后在菜鸟网络和蚂蚁金服做开发工作,一方面支撑业务团队开发各类业务系统,另一方面在自己的技术团队做基础技术建设。期间借着 Node.js 的锋芒做了不少 Web 系统,有的至今生气蓬勃、有的早已夭折...

乌柏木150阅读 12.3k评论 10

正则表达式实例
收集在业务中经常使用的正则表达式实例,方便以后进行查找,减少工作量。常用正则表达式实例1. 校验基本日期格式 {代码...} {代码...} 2. 校验密码强度密码的强度必须是包含大小写字母和数字的组合,不能使用特殊...

寒青56阅读 7.9k评论 11

JavaScript有用的代码片段和trick
平时工作过程中可以用到的实用代码集棉。判断对象否为空 {代码...} 浮点数取整 {代码...} 注意:前三种方法只适用于32个位整数,对于负数的处理上和Math.floor是不同的。 {代码...} 生成6位数字验证码 {代码...} ...

jenemy46阅读 6k评论 12

从零搭建 Node.js 企业级 Web 服务器(十五):总结与展望
总结截止到本章 “从零搭建 Node.js 企业级 Web 服务器” 主题共计 16 章内容就更新完毕了,回顾第零章曾写道:搭建一个 Node.js 企业级 Web 服务器并非难事,只是必须做好几个关键事项这几件必须做好的关键事项就...

乌柏木66阅读 6.2k评论 16

再也不学AJAX了!(二)使用AJAX ① XMLHttpRequest
「再也不学 AJAX 了」是一个以 AJAX 为主题的系列文章,希望读者通过阅读本系列文章,能够对 AJAX 技术有更加深入的认识和理解,从此能够再也不用专门学习 AJAX。本篇文章为该系列的第二篇,最近更新于 2023 年 1...

libinfs39阅读 6.3k评论 12

封面图
从零搭建 Node.js 企业级 Web 服务器(一):接口与分层
分层规范从本章起,正式进入企业级 Web 服务器核心内容。通常,一块完整的业务逻辑是由视图层、控制层、服务层、模型层共同定义与实现的,如下图:从上至下,抽象层次逐渐加深。从下至上,业务细节逐渐清晰。视图...

乌柏木44阅读 7.4k评论 6

一路从后端走来,终于走在了前端!

56.2k 声望
26.5k 粉丝
宣传栏