SQL时区问题本质是时间值在存储、查询、转换中因时区设置不一致导致逻辑错误或展示偏差；关键在于明确时间字段语义，并在数据库层、应用层、连接层协同处理。
SQL时区问题本质是时间值在存储、查询、转换过程中因时区设置不一致，导致业务逻辑出错或数据展示偏差。关键不是“统一用UTC”或“全用本地时间”，而是明确每个时间字段的语义，并在数据库层、应用层、连接层保持协同。
明确时间字段的业务含义
时间字段分三类，处理方式完全不同：
-
带时区的时间点（如用户注册时间、订单创建时间）：应存为
TIMESTAMP WITH TIME ZONE（PostgreSQL）或等效类型（如 MySQL 8.0+ 的TIMESTAMP默认按系统时区转为 UTC 存储）；插入时带时区信息（如'2024-06-15 14:30:00+08'），查询时可按需转成任意时区显示。 -
纯本地时刻（如营业开始时间 09:00）：用
TIME或CHAR(5)，不涉及时区，也不该参与跨时区计算。 -
日期（如生日、合同生效日）：用
DATE类型，只关心年月日，避免混入时间或时区。
统一数据库服务器与连接会话的时区设置
MySQL 和 PostgreSQL 都支持多级时区控制，优先级通常是：客户端连接时区 > 会话时区 > 全局时区 > 系统时区。常见隐患是应用连接未显式指定时区，导致依赖服务器默认值。
- MySQL 连接串中加
&serverTimezone=Asia/Shanghai（JDBC）或timezone='Asia/Shanghai'（Python mysql-connector）；避免用SYSTEM或UTC模糊值。 - PostgreSQL 在连接后执行
SET TIME ZONE 'Asia/Shanghai';，或在postgresql.conf中设timezone = 'Asia/Shanghai'，并确保log_timezone也同步。 - 验证方式：执行
SELECT NOW(), CURRENT_TIMESTAMP, TIMEZONE();（PostgreSQL）或SELECT NOW(), @@time_zone;（MySQL），确认返回值符合预期。
避免在 SQL 中硬写时区偏移或依赖函数隐式转换
像 NOW() + INTERVAL 8 HOUR 或 CONVERT_TZ(NOW(), '+00:00', '+08:00') 表面可行，实则脆弱——无法应对夏令时、城市政策变更（如中国已取消夏令时，但某些地区规则仍可能调整）。
- 改用命名时区名（如
'Asia/Shanghai'），数据库内置时区库会自动处理历史变更。 - 不要用
DATE(NOW())截断时间来“绕过时区”，这会让跨时区用户看到错误日期（例如 UTC 时间 2024-06-15 16:00 对应北京时间次日 00:00）。 - 聚合统计（如“今日订单量”）必须明确“今日”指哪个时区。建议在应用层传入标准时区下的日期范围，而非让数据库用
CURDATE()判定。
应用与数据库间传递时间要带时区信息
前端传时间字符串（如 "2024-06-15T14:30:00+08:00"）到后端，后端解析时必须保留时区偏移，再以带时区格式传给数据库（如 PostgreSQL 的 timestamptz 字面量）。若后端转成无时区 datetime 再插库，等于丢失上下文。
- Java 使用
OffsetDateTime或ZonedDateTime，避免LocalDateTime。 - Python 使用
datetime.datetime.fromisoformat("...+08:00")或pendulum.parse()，别用strptime忽略时区。 - API 设计上，要求所有时间字段使用 ISO 8601 格式并强制含时区（如
2024-06-15T14:30:00+08:00），后端不做“自动补时区”猜测。
时区问题不复杂但容易忽略细节。核心是把时间当作带单位的量——UTC 是基准单位，时区是换算系数，而业务语义决定该用哪种表达。只要字段定义清晰、链路传递完整、数据库配置可控，一致性就能守住。
