系统设计中 跨时区问题 解决方案

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 等时间库来完成。

正是因为前面讲到的时区问题，Moment.js 为了处理此问题，使用了一个巨大的 JSON 文件记录了不同年份之间、不同国家、不同经纬度的时区信息，另外这些信息还会和语言信息绑定导致文件非常巨大。

4.3 其它注意事项

在编程中还有一些额外的坑可能需要注意：

• 使用环境变量配置时区信息，使用应用服务器来裁决时区（没有特别业务说明的情况下），因此确保服务器配置的时区相同。
• 如果是跨国交易或者数据同步的时候，根据客户端连接到的服务器来决定操作用户所属的时区。
• 依赖应用服务器的时区信息做时区裁决，不要依赖数据库的时区设置，数据库透明存放数据即可。
• 时区配置来源有操作系统、环境变量、数据库时区、Java 启动参数，建议统一使用 Java 启动参数，避免配置出错，数据库不要做时区自动转换，避免使用 TIMESTAMP 类型。
• 在高并发的场景中获取系统时间可能有性能问题，原因是 JVM 需要访问进入系统内核态执行指令，当高并发且不需要高精度时间时可以增加缓存，但需要权衡处理。
• 有时候在处理业务时，需要考虑自然月问题，需要特别注意。
• 关于时间同步问题中，还有一个墙上时钟和单调时钟的问题。墙上时钟是指根据日历获取时间，会受到时间校对回拨的问题，而单调时钟是指系统启动后的秒数，它不会回拨。在使用 NTP 服务时，可以配置为 NTPD 模式，通过调慢时间频率避免回拨。

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

夏令时（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·

相关阅读：

---

专注架构技术研究，一起跨越职业瓶颈！

关注公众号，免费领学习资料

如果您觉得还不错，欢迎关注和转发~