必须统一用UTC存储并由应用层处理时区转换。原因包括：MySQL的TIMESTAMP自动转换依赖不可控的会话时区，易受连接池、主从复制等影响；存在2038年上限；CONVERT_TZ函数依赖IANA时区表且不支持夏令时边界，还会导致索引失效；推荐方案是写入前转UTC、用DATETIME(3)存纯UTC时间、读出后在应用层按需转换，并严格配置数据库和连接层时区为UTC。
统一用 UTC 存储，所有时区转换逻辑移出数据库，放到应用层做——这是唯一能避免混乱的底线。
为什么不能依赖 MySQL 的 TIMESTAMP 自动转换
很多人以为设了 SET time_zone = '+00:00' 或用 TIMESTAMP 就万事大吉，结果上线后发现订单时间在新加坡查是下午，在纽约查变成凌晨，还对不上日志。问题出在：MySQL 的自动转换只作用于当前会话时区，而 Web 应用通常复用连接池，不同请求可能共享同一个连接，time_zone 设置极易被覆盖或遗忘；更麻烦的是，主从复制、备份恢复、ETL 工具等场景下，会话时区根本不可控。
-
TIMESTAMP的自动转换是“隐式”的，调试困难，一旦出错很难定位是哪次查询漏设了时区 - 如果应用层写入的是本地时间（比如前端传
"2026-06-04 15:30"），而连接时区恰好是Asia/Shanghai，MySQL 会把它当成东八区时间转成 UTC 存，但你根本没意识到这个转换发生了 -
TIMESTAMP的 2038 年上限对长期运行的系统是硬伤，金融、IoT 类项目必须避开
推荐方案：全链路强制 UTC + 应用层转换
核心动作只有三步：写入前转 UTC、存储用 DATETIME(3)、读出后按需转本地。不依赖 MySQL 时区配置，也不碰 CONVERT_TZ() 函数。
- 前端提交时间时，必须附带用户时区标识（如
"Asia/Shanghai"），或由浏览器通过Intl.DateTimeFormat().resolvedOptions().timeZone获取 - 后端收到后立刻调用语言原生 API 转为 UTC 时间点（例如 Java 的
ZonedDateTime.parse(...).withZoneSameInstant(ZoneOffset.UTC)，Python 的datetime.astimezone(timezone.utc)） - 存入数据库时，用
DATETIME(3)字段，值为纯 UTC 时间字符串（如"2026-06-04 07:30:00.123"），不带任何时区信息 - 读取时，把
DATETIME值当作 UTC 时间再转目标时区——不是靠数据库函数，而是应用层做
CONVERT_TZ() 看似方便，但生产环境慎用
这个函数在 SQL 层做时区转换，表面省事，实际埋雷最多。它要求 MySQL 必须预装 IANA 时区表，而云数据库（如阿里云 RDS、腾讯云 CDB）默认不开启，手动导入需要 DBA 权限且重启服务；更关键的是，它无法处理夏令时切换边界（比如 2026 年 3 月 9 日美国开始夏令时，凌晨 2 点跳到 3 点，CONVERT_TZ() 在某些版本里会重复计算或跳过一小时）。
- 如果你非要用，先确认
SELECT COUNT(*) FROM mysql.time_zone_name;返回非零值，否则一律返回NULL - 永远别在
WHERE子句里用CONVERT_TZ(created_at, 'UTC', 'Asia/Shanghai') > '2026-06-04'——这会导致索引失效，全表扫描 - 聚合类查询（如
GROUP BY DATE(CONVERT_TZ(...))）的结果在跨夏令时日期下不可靠
数据库和连接层必须做的最小配置
哪怕你坚持应用层转换，以下两处也必须硬性约束，否则等于没设防：
- MySQL 全局
time_zone设为'+00:00'：SET GLOBAL time_zone = '+00:00';，防止运维误操作或新实例继承系统时区 - JDBC 连接串强制指定
serverTimezone=UTC，PHP 的 PDO 加&timezone=UTC，Node.js 的 mysql2 配置timezone: 'Z'——这是堵住连接级时区污染的最后一道缝 - 建表时所有时间字段显式用
DATETIME(3)，禁用TIMESTAMP和字符串类型（如VARCHAR存时间），并加注释说明“此字段存储 UTC 时间”
真正容易被忽略的不是技术选型，而是时间值在进出应用边界的那一瞬间：前端发来的“现在”到底指什么？是设备系统时间？浏览器时区时间？还是用户手动选的某个城市时间？这个语义必须在 API 文档里白纸黑字定义清楚，否则再严谨的存储方案也会在第一公里就崩掉。
