- 当前位置：首页 >人工智能 >你知道程序是怎么处理时区问题的么？
你知道程序是怎么处理时区问题的么？
发布时间：2025-11-05 11:01:33 来源：码上建站 作者：IT科技类资讯
本文转载自微信公众号「三太子敖丙」，知道作者三太子敖丙 。程序处理转载本文请联系三太子敖丙公众号。时区
前言
在实际业务开发中，问题会碰到夏令时，知道闰秒，程序处理时区转换的时区问题，这些问题都需要从业务角度去考虑，问题保证用户在任何地区看到的知道数据都一致的，这就需要MySQL数据库、程序处理后端服务以及前端服务做相应的时区处理才能完成。
最近我也刚好在开发的问题时候遇到了，所幸就写下这个比较冷门的知道文章，跟大家聊聊夏令时，程序处理闰秒，时区时区转换在实际开发过程中的解决方案。
夏令时
夏令时介绍
夏令时(Daylight Saving Time：DST)：又称"日光节约时制"，是一种为节约能源而人为规定地方时间的制度，在这一制度实行期间所采用的统一时间称为“夏令时间”。
一般在天亮早的夏季人为将时间调快一小时，可以使人早起早睡，减少照明量，以充分利用光照资源，云南idc服务商从而节约照明用电，除了夏令时外还有冬令时，采用的是本地的标准时间。
可以看到意大利是有夏令时制，夏令时的时间从3月28日到10月31日，冬令时(本地标准时间)是从11月1日到3月27日，在夏令时时段内，时间比标准时间快一个小时，例如罗马市的时区GMT + 1:00，标准时间为10:00:00，在夏令时的时间就是11:00:00，冬令时的时间就是10:00:00。
CET (中欧标准时间) 是UTC + 01:00时区的名称之一，比UTC(世界标准时间)提前1个小时，与UTC的时间偏差可写为+01:00，在冬天使用，在夏季时使用CEST - 中欧夏令时间 (UTC + 02:00，提前一个小时)。
LInux时区
Linux服务器的亿华云系统时间的校准是通过NTP(Network Time Protocol)服务来实现，每隔一段时间会跟时钟源进行校对，确保Linux系统时间的准确性，同时Linux操作系统支持不同国家及地区的时区设置，所有时区信息位于/usr/share/zoneinfo目录下，如果需要设置时区，只需要将/etc/localtime软链接到一个具体的地区即可，如果这个地区有DST机制，那么Linux会自动在DST和标准时间之间切换，不需要额外的代码来处理。
## Linux支持的区域信息 $ ls -ltr /usr/share/zoneinfo/ total 320 lrwxrwxrwx 1 root root 3 10月 23 05:18 Zulu -> UCT -rw-r--r-- 1 root root 1544 10月 23 05:18 W-SU -rw-r--r-- 1 root root 1873 10月 23 05:18 WET lrwxrwxrwx 1 root root 3 10月 23 05:18 UTC -> UCT lrwxrwxrwx 1 root root 3 10月 23 05:18 Universal -> UCT -rw-r--r-- 1 root root 127 10月 23 05:18 UCT -rw-r--r-- 1 root root 1970 10月 23 05:18 CET ## 前端服务所在Linux服务器的时区 $ ls -ltr /etc/localtime lrwxrwxrwx 1 root root 33 11月 1 06:20 /etc/localtime -> /usr/share/zoneinfo/Asia/Shanghai通过zdump命令查看下意大利罗马的时区属性。
$ zdump -v /usr/share/zoneinfo/CET /usr/share/zoneinfo/CET Sun Mar 28 00:59:59 2021 UT = Sun Mar 28 01:59:59 2021 CET isdst=0 gmtoff=3600 /usr/share/zoneinfo/CET Sun Mar 28 01:00:00 2021 UT = Sun Mar 28 03:00:00 2021 CEST isdst=1 gmtoff=7200 #2021年夏令时开始 /usr/share/zoneinfo/CET Sun Oct 31 00:59:59 2021 UT = Sun Oct 31 02:59:59 2021 CEST isdst=1 gmtoff=7200 #2021年夏令时结束从上面的信息可以看到，2021年夏令时的开始时间是Sun Mar 28 01:00:00，结束时间为Sun Oct 31 00:59:59，isdst = 1说明当前处于DST时段，gmtoff=7200表示与格林治时间的offset，单位秒，即UTC + 02:00，也称为CEST时间，这说明Linux操作系统已经自动实现了下夏令时DST的服务器托管自动切换。
处理夏令时
举个例子，意大利罗马的客户需要开发一个税务系统，用于国内各地市的税收记账，由于意大利是有夏令时制，就需要考虑夏令时DST的处理，在开发的过程中，涉及时间问题的包括MySQL数据库(mysql-server)，后端服务(backend-service)以及前端服务(frontend-service)三个方面，下面就从三个层面分析如何去处理DST。
前端处理
业务对前端的要求是：不管使用的是移动端还是PC端，都应该正确的显示当时时间，包括有夏令时制的时间。
如果在中国的话，就比较好处理，没有DST机制，统一使用东八区即GMT/UTC + 08:00即可，前端服务的时间直接取Linux服务服务器的系统时间，Linux的时区只需要设置为Asia/Shanghai即可，前端不需要做任何时间的转入转出。
**转入：**指POST请求写入数据，user —> frontend-service —> backend-service —> mysql-server，例如缴税接口。
**转出：**指GET请求查询数据，mysql-server —> backend-service —> frontend-service —> user，例如查询接口。
不过开心的是，Linux操作系统已经自动实现了DST转换，在前端不需要做任何处理，设置Linux时区为CET。
# 修改LInux时区为CET，也可以通过timedatectl命令修改。 $ ln -sf /usr/share/zoneinfo/CET /etc/localtime这样在意大利国内的用户的通过终端(移动端或PC端)，登录系统缴税或查询时，用户时间和前端服务的时间完全一致，即完成如下这一步的处理。
后端处理
我们了解了前端Linux服务器的时区设置为CET，就能自动处理意大利DST夏令时转换了，后端Java程序部署在Linux服务器上，将其时区设置跟前端一样，也是CET时区，后端只需要接收前端传过来的值进行MySQL的CRUD操作即可，税务表的结构如下：
CREATE TABLE `tax_form` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT 主键id, `tax_id` varchar(20) NOT NULL DEFAULT COMMENT 税务编号, `amount` decimal(12,4) NOT NULL DEFAULT 0.0000 COMMENT 纳税金额, `tax_payer_id` varchar(20) NOT NULL DEFAULT COMMENT 纳税人编号, `status` tinyint NOT NULL DEFAULT 0 COMMENT 缴税状态, `audit_time` datetime NOT NULL DEFAULT 0000-00-00 00:00:00 COMMENT 审核时间, `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 修改时间, PRIMARY KEY (`id`) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT=税务记录表;主要看一下缴税和审核接口，分别的对应的SQL语句如下：
缴税
-- 缴税接口的对应的SQL insert into tax_form(tax_id,amount,tax_payer_id,status) values(T001, 1234.56, U001, 0)审核
-- 修改审核状态 update tax_form set status = 1, audit_time = 2021-01-07 12:02:30 where tax_payer_id = U001;涉及时间的字段有两类
**公共字段：**create_time，update_time这些是每个表必须有的时间字段，而且默认都是MySQL的CURRENT_TIMESTAMP，取的MySQL server的当前系统时间，而这个时间是跟MySQL的时区time_zone设置不同而变化的，同时MySQL也是支持夏令时DST自动转换的。
业务字段：audit_time审核时间属性是由前端页面传到后端进行处理，后端无需做任何转换。
MySQL处理
MySQL也是支持夏令时DST机制，不过设置时区time_zone只能设置为地区(类似Linux设置时区一样)，不能石永红MySQL设置的时区的相关变量
mysql> show variables like %zone%; +------------------+--------+ | Variable_name | Value | +------------------+--------+ | system_time_zone | CST | -- 数据库服务器的当前时区，不可修改，CST这里指的是中国标准时间(China Standard Time UTC+08:00，即东八区) | time_zone | SYSTEM | -- 数据库时区，默认跟服务器保持一致，可修改。目前是东八区，修改为意大利时区，即东一区。
mysql> select now(); +---------------------+ | now() | +---------------------+ | 2021-01-07 13:43:31 -- 修改数据库时区为零时区，即。 mysql> set time_zone = CET; ERROR 1298 (HY000): Unknown or incorrect time zone: CET -- 尝试通过+0:00方式修改，可以成功修改。 mysql> set time_zone = +1:00; Query OK, 0 rows affected (0.00 sec)MySQL存储时区信息的数据字典
mysql> show tables from mysql like %time_zone%; +-------------------------------+ | Tables_in_mysql (%time_zone%) | +-------------------------------+ | time_zone | -- 时区信息 | time_zone_leap_second | -- 时区闰秒信息 | time_zone_name | -- 时区名 | time_zone_transition | -- 时区转换 | time_zone_transition_type | -- 时区转换类型默认情况下，这些表都是空的，需要通过MySQL专门提供的命令mysql_tzinfo_to_sql导入，数据会被插入到表time_zone相关的表中。
# Linux下的时区信息/usr/share/zoneinfo通过命令mysql_tzinfo_to_sql加载到相关的time_zone表中。 $ mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql执行完成之后，看一下表中的数据，再尝试设置时区为CET。
mysql> select * from mysql.time_zone_name where name like %CET%; +------+--------------+ | Name | Time_zone_id | +------+--------------+ | CET | 373 | -- 设置时区为CET mysql> set time_zone = CET; Query OK, 0 rows affected (0.02 sec) mysql> select now(); +---------------------+ | now() | +---------------------+ | 2021-01-07 10:00:36 |而且也支持时区转换，例如将北京时间转换成罗马时间。
-- 北京时间17:00:00转换成CET的罗马时间就是10:00:00 mysql> select convert_tz(2021-01-07 17:00:00, Asia/Shanghai, CET) as time; +---------------------+ | time | +---------------------+ | 2021-01-07 10:00:00 |我们要解决的问题是：MySQL设置time_zone=CET后是否能自动实现DST转换，如果可以的话，那么用户端、前端服务、后端服务以及MySQL服务器时区就统一为CET，同时都能自动处理DST，从上面的zdump -v /usr/share/zoneinfo/CET命令输出可以看到，2021年意大利的夏令时从3月28号01:59:59号开始，也就是时间调快一小时。
-- 01:59:59时间点，没有发生DST切换。 mysql> select convert_tz(2021-03-28 01:59:59, +1:00, CET) as time; +---------------------+ | time | +---------------------+ | 2021-03-28 01:59:59 | -- 02:00:00时间点，确实发生DST切换，从02:00:00调快了一小时变成了03:00:00 mysql> select convert_tz(2021-03-28 02:00:00, +1:00, CET) as time; +---------------------+ | time | +---------------------+ | 2021-03-28 03:00:00 | -- 将+1:00时间换成CET，结果也是一样的，发生了DST切换。 mysql> select convert_tz(2021-03-28 02:00:00, CET, CET) as time; +---------------------+ | time | +---------------------+ | 2021-03-28 03:00:00 |从上面的结果可以看到，当time_zone设置成地区/城市，系统会自动解决夏令时DSTQ切换问题，如果设置time_zone=+1:00’这种方式就失去了夏令时机制，目前在MySQL数据库中，在初始化time_zone相关表元数据以后，MySQL就可以自己完成夏令时的修正，不需要额外的服务处理。
对于AWS RDS的来说，time_zone是可以选择地区/城市的，也就是支持夏令时的自动切换。
处理夏令时总结
通过上面的分析可以知道，Linux服务器和MySQL服务器都可以自动处理DST切换，前提是需要设置Linux的时区和MySQL时区为地区，例如都设置为CET。
闰秒
指为保持协调世界时接近于世界时时刻，由国际计量局统一规定在年底或年中(也可能在季末)对协调世界时增加或减少1秒的调整。最近一次闰秒在北京时间2017年1月1日7时59分59秒(时钟显示07:59:60)出现。
在实际的业务系统，受闰秒影响的有Linux服务器，Java代码以及MySQL数据库，我们来看看它们分别是怎么解决的LeapSecond问题的。
Linux服务器
对于大多数新的linux内核(2.6.x内核以后是支持LeapSecond，在这之前可能会导致Linux Kernel Crash)，在设计时都是支持闰秒的，Linux操作系统时间是通过NTP服务来和时钟源来进行同步，NTP会一级一级地下发闰秒事件通知直到最边缘的NTP服务器，然后NTP就会把闰秒通知给客户端的操作系统，由操作系统来处理闰秒通知。
对于闰秒2017-01-01 07:59:60，Linux内核需要处理这个时间，就需要做一些特定的处理，一般会有以下三种方案。
后退一秒 停止一秒 真正的增加一秒第一种方式会导致一些基于timestamp的消息通知乱序了，而第二种会导致出现两个一模一样的timestamp，而最后一种不会出现timestamp的问题，也是后面Linux内核选择的处理方案。
mysql> select UNIX_TIMESTAMP(2017-01-01 07:59:59) as nts; +------------+ | nts | +------------+ | 1483257599 | $ date -d @1483257599 --utc Sun Jan 1 07:59:59 UTC 2017 $ date -d @1483257600 --utc Sun Jan 1 08:00:00 UTC 2017从这里可以看到，Linux采用的是第三种方案：真正的增加一秒，这也符合业务系统的需求。
Java代码
Java代码的System.currentTimeMillis()会产生闰秒60，是取决于Linux操作系统的，在Linux Kernel 2.6.x之后已经fix了LeapSecond问题。
MySQL数据库
上面看到了在MySQL下已经有了mysql.time_zone_leap_second数据字典，说明已经支持了LeapSecond，处理方案跟Linux类似。
-- 创建一张测试表存储timestamp时间戳 CREATE TABLE ls( id bigint NOT NULL COMMENT id, ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id)); -- 设置数据库时区为UTC mysql> set time_zone = UTC; mysql> set timestamp = 1483257599; --对应时间：2017-01-01 07:59:59 mysql> insert into ls(id) values(1); mysql> set timestamp = 1483257600; --对应时间：2017-01-01 07:59:60 mysql> insert into ls(id) values(2); -- 可以看到MySQL对闰秒进行了处理，将07:59:60转换成了08:00:00。 mysql> select id, ts, unix_timestamp(ts) from ls; +----+---------------------+--------------------+ | id | ts | unix_timestamp(ts) | +----+---------------------+--------------------+ | 1 | 2017-01-01 07:59:59 | 1483257599 | | 2 | 2017-01-01 08:00:00 | 1483257600 | -- 通过闰秒时间查询会报错 mysql> select * from ls where ts = 2017-01-01 07:59:60; ERROR 1525 (HY000): Incorrect TIMESTAMP value: 2017-01-01 07:59:60 mysql> select * from ls where ts = 2017-01-01 08:00:00; +----+---------------------+ | id | ts | +----+---------------------+ | 2 | 2017-01-01 08:00:00 |跨境系统的时间处理
上面介绍的意大利罗马的税务系统，其实属于政企业务，只服务于国内的用户的需求，不涉及海外用户的请求，相对来说地区和人员都比较固定，但是像这种跨境电商巨头ebay，它服务的用户遍布全球各地，而且每个地区的时区不同，同时每个时区的夏令时DST的起始时间也不一样，我们要解决的是要根据客户所在地区显示正确的时间(包括DST)，跟前面的DST处理一样也涉及到三端处理：前端服务(frontend-service)，后端服务(backend-service)以及MySQL数据库(mysql-server)。
从这个图上可以看到，前端服务的UI层跟用户所在的地区时间要完全一致，至于后端服务和MySQL如何处理时间，对于用户来说根本不关心的，这就要求前端必须要根据不同地区，不同时区，不同夏令时DST产生不同的时间的用户进行转换处理，不同地区的时间转换目前前端(Vue/React)已经有现成的插件可直接使用。
同时希望只在前端处理用户时间的转入和转出，后端和MySQL数据库不做任何修改就能完成业务处理和数据存储。
北京用户在UTC + 8也就是东八区，而罗马用户在UTC + 1东一区，都是在UTC的基础上做处理，那我们就可以将时区都设置为UTC，然后根据用户所在地区进行相应的处理。
MySQL处理
设置MySQL数据库的时区为UTC，不管用户来自哪个地区存储在数据库的时间都是UTC，包括公共时间字段(创建时间，修改时间)以及业务时间字段(交易开始时间，交易结束时间)。
-- 设置数据库时区为UTC，即零时区
-- 设置数据库时区为UTC，即零时区 set global time_zone = UTC后端处理
MySQL时区是UTC，那么后端服务的所在的Linux Server时区统一设置为UTC，跟MySQL保持一致，这样后端就不需要做任何转换。
前端处理
前端拿到标准时区UTC的数据，统一根据用户所在时区进行转换，这样保证与后端数据时区的一致性，前端根据实际情况进行渲染。一般来讲，前端将时间数据传递到后端，后端封装成timestamp后存储在MySQL中对应timestamp类型(MySQL中的timestamp是不区分时区的，例如数据库是UTC 02:00:00，北京用户使用ebay在CST 10:00:00下单，数据库中的订单表的create_time就应该存储2020-12-03 10:00:00)，同时前端查询数据的也要做相应的转换处理。
定时任务
后端服务一般都会一些定时任务，这个时间一般取自Linux OS的时间，跟前端没关系，基于Linux的UTC时区做相应的调整即可。
总结
上面介绍了夏令时，闰秒以及跨境系统的时间处理问题，主要涉及到MySQL数据库，后端服务以及前端服务三个层面，对于夏令时，闰秒的转换处理，Linux和MySQL都可以自动完成处理，不需要额外转换;对于跨境系统的时间处理，通过设置Linux和MySQL时区为UTC，只需要前端服务处理不同地区用户时间问题，降低了系统改造的风险，今天就聊这么多，希望对大家有所帮助。
- 上一篇：一早起来打开电脑，无法启动显示 no such device blablablagrub rescue>灰常的茫然，无奈，只得开启家中的那台老家伙。一顿baidu google 后，大概清楚是因为昨天晚上的自动升级导致，grub加载软件出了些问题。网上有两种解决方法：本人尝试一种：成功了！ 由于这个问题相当普遍，所以写个小报告，为后人指点迷津～～～本人电脑装有xp 和 ubuntu10.04 。问题描述：开机初使化过程中出现的grub错误，原因可能多种，我这是由于升级导致的原因： 主引导记录MBR消失了。解决方法：一种是在windows中修复MBR（mbtfix。Exe）另一种是在ubuntu中修复MBR普及下知识MBR：The MBR may be used for one or more of the following:Holding a disks primary partition table.Bootstrapping operating systems, after the computers BIOS passes execution to machine code instructions contained within the MBR.Uniquely identifying individual disk media, with a 32-bit disk signature; even though it may never be used by the machine the disk is running on.我是通过第二种方法：自行制作一个livecd，一种可以自启动的linux 安装盘 。我没法烧cd，所以通过U盘制作了一个启动盘： 网址： http://www.ubuntu.com/desktop/get-ubuntu/download上面有很详细的步骤。1.首先下载一个ubuntu的iso镜像文件2.下载universal usb installer3.运行installer 將u盘制作成启动盘（移动硬盘不行）4设置电脑的加载顺序，“先启动usb设备”。重新启动5.直接启动ubuntu，打开terminal。输入 ：sudo apt-get install lilosudo lilo -M /dev/sda mbr(忽略所有警告，我们只要mbr)6，重启，修改加载顺序，一切正常～～～
- 下一篇：富勒G60（豪华、高性能、环保，一辆领先的电动SUV）
- 佳能242.8挂机镜头的全面评测（探索佳能242.8挂机镜头的性能和适用性能力）
- Idea+Jrebel+Docker 远程热部署+调试Javaweb项目
- MIT开发Twist编程语言：专门解决量子计算数据纠缠问题
- 使用 CMake 和 VSCodium 设置一个构建系统
- 以疯卖酷品——探索独特品牌营销方式（创新、激情、疯狂，为酷品打造销售奇迹）
- 携程酒店慢查询治理之路
- 齐活了，Grafana 发布大规模持续性能分析开源数据库 - Phlare
- Java 写出来的短信转发器，希望能成为你的日常小助手
- 探索诺基亚X7-00的卓越表现与功能（一款引人注目的智能手机助您领略新的移动体验）
- 解读甲骨文再创新：多云、融合
随便看看
- Copyright © 2025 Powered by 你知道程序是怎么处理时区问题的么？,码上建站 滇ICP备2023006006号-47sitemap