一、背景
假如开发一套统一的系统产品，供遍布全球的所有分公司使用。
产品功能设计中，经常会遇到一场活动，分跨不同时区，系统需要显示不同时区的时间，同时希望跨时区的用户可以同一时间开始，同一时间结束。
对于类似跨时区处理问题，那我们该如何设计实现呢？
二、几个重要概念
- 时区
划分时区是为了便于人们进行跨地区的交流、协作和管理。
时区的划分以地球表面按经线从东到西划成一个个区域，每隔经度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即可完成时区设置。
#设置时区
tzselect3.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) 的地区，夏天时钟拨快一小时，冬天再拨回标准时间。
那为什么我国没有夏令时呢？
其实不使用夏令时也能实现节约能源、减少照明成本的目的，只不过把调整人们生活节奏的权利给到了具体场景。在学校，会使用夏季和冬季课表，在工作环境中，某些公司也会针对下冬夏调整上班时间。
六、阅读更多及参考文献
本文参考资料：
