1. 为什么日期类型选型是个"坑"
在单体应用时代，日期字段选什么类型往往取决于"当时用的那个数据库"。但一旦系统需要支持多数据库（MySQL、PostgreSQL、Oracle、SQL Server、达梦、人大金仓等），或者需要做数据库迁移、信创适配，日期类型就会成为最容易踩坑的地方：
- 同一个
DATE，在 MySQL 里只存日期，在 Oracle 里却带时分秒； - 同一个
TIMESTAMP，在 MySQL 里受时区影响，在 PostgreSQL 里是"带时区的时间戳"，在 Oracle 里又是另一套语义； - 精度不一致：有的支持毫秒，有的支持微秒，有的默认只到秒；
- 时区处理不一致：有的存 UTC，有的存本地时间，有的干脆不带时区信息。
结果就是：本地测试一切正常，上线后出现"时间差 8 小时""日期少一天""毫秒被截断"等经典问题。
本文从字段语义出发，给出一套可落地的跨数据库日期类型选型方案。
2. 先分清三类时间语义
选型的第一步不是看数据库，而是看业务语义。日期时间字段本质上只有三类：
| 语义类型 | 典型场景 | 是否需要时区 | 是否需要时分秒 |
|---|---|---|---|
| 纯日期 | 生日、账单日、统计日期 | 否 | 否 |
| 时间点（瞬时） | 创建时间、支付时间、日志时间 | 是 | 是 |
| 本地时间（墙上时间） | 营业时间、预约时间、班次 | 否（但依赖地区） | 是 |
把字段归到这三类之后，选型就变成了"每类语义对应哪种物理类型"的映射问题。
3. 主流数据库日期类型对照
| 语义 | MySQL | PostgreSQL | Oracle | SQL Server | 通用建议 |
|---|---|---|---|---|---|
| 纯日期 | DATE |
DATE |
DATE（含时分秒，需注意） |
DATE（含时间） |
用 DATE，但代码层只取日期部分 |
| 时间点（带时区） | TIMESTAMP（受 time_zone 影响） |
TIMESTAMPTZ |
TIMESTAMP WITH TIME ZONE |
DATETIMEOFFSET |
统一存 UTC |
| 时间点（不带时区） | DATETIME |
TIMESTAMP |
TIMESTAMP |
DATETIME2 |
存 UTC 值，语义上视为瞬时 |
| 本地时间 | DATETIME |
TIMESTAMP |
TIMESTAMP |
DATETIME2 |
明确约定"不做时区转换" |
| 高精度 | DATETIME(6) |
TIMESTAMP(6) |
TIMESTAMP(6) |
DATETIME2(7) |
按需指定精度 |
几个必须记住的差异点：
- MySQL 的
TIMESTAMP有 2038 年问题 ，且会随会话时区自动转换；DATETIME范围更大（1000--9999 年）且不做时区转换。 - PostgreSQL 的
TIMESTAMP不带时区 ，TIMESTAMPTZ才是带时区的；很多人误以为TIMESTAMP带时区。 - Oracle 的
DATE包含时分秒 ，只有日期需求时要用TRUNC()或改用DATE+ 约束。 - SQL Server 的
DATE是纯日期 （2008 起），DATETIME精度只有 3.33ms，推荐用DATETIME2。
4. 推荐选型方案
4.1 纯日期字段
统一使用 DATE 类型，代码层使用 java.time.LocalDate（Java）或 date（Python）。
sql
-- 各数据库写法基本一致
CREATE TABLE user_profile (
birthday DATE
);注意：Oracle 的 DATE 会带时分秒，插入时建议显式 TRUNC(SYSDATE)，读取时在应用层截断。
4.2 时间点字段（推荐方案）
核心原则：统一存 UTC，统一用"不带时区"的类型承载 UTC 值。
这是跨数据库兼容性最好的方案，因为：
- 所有数据库都支持不带时区的时间类型；
- 存储的是 UTC 绝对值，不依赖数据库会话时区；
- 展示时由应用层按用户时区转换，职责清晰。
sql
-- MySQL
created_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3)
-- PostgreSQL
created_at TIMESTAMP(3) NOT NULL DEFAULT (now() AT TIME ZONE 'UTC')
-- Oracle
created_at TIMESTAMP(3) NOT NULL DEFAULT SYS_EXTRACT_UTC(SYSTIMESTAMP)
-- SQL Server
created_at DATETIME2(3) NOT NULL DEFAULT SYSUTCDATETIME()应用层对应类型：
java
// Java：用 Instant 表示瞬时，落库前转 UTC
private Instant createdAt;
python
# Python：用带时区的 datetime，统一转 UTC
from datetime import datetime, timezone
created_at: datetime # 存储前 .astimezone(timezone.utc)4.3 本地时间字段
营业时间、预约时段这类"墙上时间"，不要做时区转换，直接存字面值：
sql
-- 统一用不带时区的类型
open_time TIME
close_time TIME应用层用 LocalTime / LocalDateTime，并在字段注释中明确写"本地时间，不做时区转换"。
5. 跨数据库兼容的工程实践
5.1 用 ORM 或迁移工具屏蔽差异
如果项目使用 JPA/Hibernate、MyBatis-Plus、SQLAlchemy、Flyway 等，尽量让框架处理类型映射：
java
@Entity
public class Order {
@Column(name = "created_at", nullable = false, updatable = false)
private Instant createdAt; // Hibernate 6 默认映射为 UTC 时间戳
@Column(name = "biz_date")
private LocalDate bizDate; // 映射为 DATE
}5.2 统一时区配置
yaml
# Spring Boot
spring:
jackson:
time-zone: UTC
date-format: yyyy-MM-dd'T'HH:mm:ss.SSS'Z'数据库连接串也建议显式指定时区，例如 MySQL 的 serverTimezone=UTC，避免驱动层隐式转换。
5.3 精度统一
跨库时最容易出问题的是精度。建议：
- 业务需要毫秒 → 统一
(3)； - 需要微秒 → 统一
(6)； - 不需要 → 明确用秒级，避免不同库默认精度不同导致比较结果不一致。
5.4 避免使用数据库特有函数做业务计算
DATE_ADD、DATEADD、ADD_MONTHS 等函数各库写法不同。日期加减、格式化尽量放到应用层，SQL 中只做简单比较和范围查询。
6. 常见坑与规避
| 坑 | 现象 | 规避方式 |
|---|---|---|
MySQL TIMESTAMP 时区转换 |
换时区后时间变了 | 用 DATETIME 存 UTC |
MySQL TIMESTAMP 2038 问题 |
2038 年后溢出 | 用 DATETIME |
PostgreSQL TIMESTAMP 误认为带时区 |
跨时区数据错乱 | 明确用 TIMESTAMPTZ 或统一存 UTC |
Oracle DATE 带时分秒 |
日期比较不相等 | 用 TRUNC() 或改类型 |
| 精度截断 | 毫秒丢失导致排序错乱 | 显式指定精度 |
| 字符串存日期 | 无法索引、比较错误 | 一律用原生日期类型 |
7. 选型决策清单
落地时按以下顺序判断：
- 这个字段是"日期"还是"时间点"还是"本地时间"？
- 如果是时间点 → 统一存 UTC，用不带时区的类型（
DATETIME/TIMESTAMP/DATETIME2）。 - 如果是纯日期 → 用
DATE，注意 Oracle 的特殊性。 - 如果是本地时间 → 用不带时区类型，并在注释中声明不做转换。
- 精度按业务需要显式指定，全库统一。
- 时区转换只在应用层做，数据库只负责存储。
8. 小结
跨数据库日期类型选型的本质，不是"哪个数据库的类型更好"，而是先把业务语义分清楚，再用最通用的类型承载它。
一句话总结：纯日期用 DATE，时间点统一存 UTC 用不带时区类型，本地时间不做转换，精度显式声明，时区转换交给应用层。 按这套规则，无论底层是 MySQL、PostgreSQL、Oracle 还是国产数据库，日期字段都能保持一致的行为。