hello，大家好，我是张张，「架构精进之路」公号作者。

一、背景

假如开发一套统一的系统产品，供遍布全球的所有分公司使用。

产品功能设计中，经常会遇到一场活动，分跨不同时区，系统需要显示不同时区的时间，同时希望跨时区的用户可以同一时间开始，同一时间结束。

对于类似跨时区处理问题，那我们该如何设计实现呢？

二、几个重要概念

• 时区

划分时区是为了便于人们进行跨地区的交流、协作和管理。

时区的划分以地球表面按经线从东到西划成一个个区域，每隔经度15°划分一个时区，规定相邻区域的时间相差1小时，如下图所示：

• 格林尼治时间

英国皇家格林尼治天文台，UTC/GMT 0 (零时区)。

• 中国时区

有东五区、东六区、东七区、东八区、东九区，新疆在东五、东六、而东北在东九区，但解放后我们国家统一采用北京时间（东八区）为准。

• UTC

Coordinated Universal Time，世界统一时间，中国是UTC+8。

• GMT

Greenwish Mean Time，以地球公转和自转来计算时间，而UTC以原子钟来计算时间。

• UNIX时间戳

1970年1月1日（UTC/GMT的午夜）开始所经过的秒数，因此，不同的时区的时间戳是相同的。

三、操作系统、数据库时区设置

3.1 Linux 中设置时区

一台Linux服务器有两个时间源，一个是硬件时间，即服务器硬件CMOS维护的时间，还有一个是软件时间，即操作系统维护的时间，前者通过 hwclock 命令来访问，后者则主要通过date命令来访问。

date 是最常用的时间相关的命令，例如：

# 获取当前时间
$ date
Fri Apr 26 15:22:16 CST 2024

# 以特定格式输出当前时间，格式字符串前以"+"开头，例如获得当前时间的epoch
$ date +%s
1714117833

# 设置当前时间
$ sudo date -s "2024-04-25 00:00:00"
Thu Apr 25 00:00:00 CST 2024

如果是云服务器的话，中国区服务器默认都是 UTC+8，海外机器则是 UTC+0，关于这个大家再需要确认一下。

Linux 使用 tzselect 调整时区

该命令会向导式的选择洲区、国家和城市，然后在/usr/share/zoneinfo下会生成时区的文件，将该文件覆盖 /etc/localtime 即可完成时区设置。

#设置时区
tzselect 

3.2 MySQL 中设置时区

先登录到mysql 安装所在的机器。

-- 看下当前的mysql时区设置
show variables like "%time_zone%";

下图显示 SYSTEM，表示用的默认时区。

我们可以修改成 +8 的北京所在时区，操作如下：

set global time_zone = '+8:00'; 
set time_zone = '+8:00';

如上修改，MySQL如果重启后，又会恢复之前的设置。

下面介绍一种设置，让重启永久生效的方案：修改设置，重启永久生效。

修改配置文件 /etc/my.cnf

[mysqld]
default-time_zone = '+8:00'

重启 MySQL 生效

systemctl stop mysqld.service
systemctl start mysqld.service

四、系统跨时区设计

现在我们回到正规，谈谈如何解决上面开篇提出的问题。

4.1 服务端中的时间处理

既然时区的处理不能在客户端做，换言之就必须在服务端实现。

这样就需要解决两个问题：时间的保存和获取。

客户端传来的时间为客户端所在时区的当地时间，服务端接收到客户端发送的时间后，需要基于客户端相应时区转换成UTC时间才能保存到数据库。

所有后端暴露的接口中的时间对象，全部以 UTC 时间表示。

同时，所有后端在存储、计算、传输时间时，也统一使用 UTC 时间。由于 DB 存储时间时，时区信息会被丢掉，因此应保证丢掉的时区，是大家明确约定清楚的无歧义的，即 UTC。这样一来，数据库中的所有时间字段也都没有歧义。

4.2 前端中的时间

时间在前端中的应用比较简单，通常的方案是：后端直接返回 ISO 标准本地时间，避免 UTC 在前端再次格式化和处理时区，否则会把问题变得更加复杂（时区设置只发生在应用服务器中）。

如果有需要处理跨时区的业务场景需，可以让用户选择时区，并在任何时候都将处理后的时区信息放到时间字符串中。

前端的时间格式化比较简单，可以使用 Day.js 和 Moment.js 等时间库来完成。

4.3 其它注意事项

在开发过程中，还有一些额外注意的细节：

• 业务处理时，要考虑自然月问题
• 用户时区创建、编辑不同操作情况下，时区可能存在切换，需要根据服务端存储的时间作为依据
• 服务接口内部应用的时间，例如 CreatedAt、UpdatedAt时间，都应该转换为 UTC 再落库存储
• 如果是跨国交易或者数据同步的时候，根据客户端连接到的服务器来决定操作用户所属的时区。
• 依赖应用服务器的时区信息做时区裁决，不要依赖数据库的时区设置，数据库透明存放数据即可。
• 时区配置来源有操作系统、环境变量、数据库时区、Java 启动参数，建议统一使用 Java 启动参数，避免配置出错，数据库不要做时区自动转换，避免使用 TIMESTAMP 类型。
• 在高并发的场景中获取系统时间可能有性能问题，原因是 JVM 需要访问进入系统内核态执行指令，当高并发且不需要高精度时间时可以增加缓存，但需要权衡处理。
• 有时候在处理业务时，需要考虑自然月问题，需要特别注意。

五、补充知识：夏令时、冬令时

夏令时（Daylight Saving Time：DST），也叫夏时制，又称“日光节约时制”和“夏令时间”，是一种为节约能源而人为规定地方时间的制度，在这一制度实行期间所采用的统一时间称为“夏令时间”。 一般在天亮早的夏季人为将时间调快一小时，可以使人早起早睡，减少照明量，以充分利用光照资源，从而节约照明用电。

夏令时调整通常适用于：夏季日照时间相对较长，日出和日落时间发生较大变化的地方。关于夏令时的问题，人们褒贬不一。

有夏令时就会有冬令时，冬令时 通常是指当地使用的标准时间。在使用夏令时 - 日光节约时制(Daylight Saving Time) 的地区，夏天时钟拨快一小时，冬天再拨回标准时间。

那为什么我国取消夏令时呢？

我国经济的发达地区，也是人口的密集区，多数都集中在东部和东南部沿海地区，这里的昼夜时间变化并没有高纬度地区大，所以实施的效果和余地都不太大。

在学校，会使用夏季和冬季课表，在工作环境中，某些公司也会针对下冬夏调整上班时间。

六、阅读更多及参考文献

本文参考资料：

• https://en.wikipedia.org/wiki/Time_zone
• https://zh.wikipedia.org/wiki/ISO_8601
• https://www.rfc-editor.org/rfc/rfc3339?
• ??https://datatracker.ietf.org/doc/html/rfc5545?
• https://en.wikipedia.org/wiki/System_time
• https://www.iplocate.com/
• https://en.wikipedia.org/wiki/Timestamp

·END·

希望今天的讲解对大家有所帮助，谢谢！

Thanks for reading!

作者：张张，十年研发风雨路，大厂架构师，「架构精进之路」专注架构技术沉淀学习及分享，职业与认知升级，坚持分享接地气儿的干货文章，期待与你一起成长。

关注并私信我回复“01”，送你一份程序员成长进阶大礼包，欢迎勾搭。