考虑时区了吗?

2021年11月22日 阅读数:3
这篇文章主要向大家介绍考虑时区了吗?,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

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

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

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

被偷走的一天

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

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

如今使用 d.getDate() 看会获得什么?—— 是 17,没毛病!前端工程师

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

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

若是是在 Linux 下,也能够从新设置系统时间,而后用 Node 控制台来查看,以下图:设计

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

为何少了一天?code

浏览器始终使用本地时间

要问为何少一天,不妨看看 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。

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