数据库时间一致性需统一存为UTC、明确字段语义、按数据库特性选类型（如PostgreSQL用TIMESTAMPTZ、MySQL用TIMESTAMP）、应用层负责UTC转换与本地化展示，禁用NOW()等时区敏感函数。
数据库时间一致性问题，核心在于明确时间字段的语义、统一存储规范、合理处理时区转换。不建议在应用层随意做时区加减，也不该把带时区的时间（如 TIMESTAMP WITH TIME ZONE）和无时区时间（如 DATETIME 或 TIME）混用。
明确时间字段的业务含义
是“用户本地发生的时间”？还是“系统统一标准时间”？
- 登录时间、订单创建时间、日志时间等，应统一存为 UTC 时间（
TIMESTAMP类型 + 应用写入前转成 UTC），这是最推荐的做法 - 用户预约的“明天上午9点理发”，属于本地时刻，应额外保存所属时区（如
timezone VARCHAR(32)字段），不能只存一个 DATETIME - 避免使用
DATE或TIME单独存储，它们无法表达完整时间点，跨时区比对或排序会出错
数据库配置与类型选择要匹配
不同数据库对时区的支持差异大，选型和配置直接影响一致性：
- PostgreSQL：优先用
TIMESTAMP WITH TIME ZONE（简写TIMESTAMPTZ），写入时自动转为 UTC 存储，查询时按 session 时区自动转换显示；务必设置timezone = 'UTC'在postgresql.conf中，避免依赖客户端默认时区 - MySQL：
TIMESTAMP类型本质是带时区的（存储为 UTC，读写自动转换），而DATETIME是纯本地值、无时区信息；强烈建议业务时间字段全用TIMESTAMP，并设time_zone='+00:00'全局参数 - SQL Server：用
DATETIMEOFFSET类型存带偏移的时间，避免用DATETIME2存含时区语义的数据
应用层写入与读取必须有统一规则
数据库只是容器，真正决定一致性的，是应用如何使用它：
- 所有写入时间，先由应用将用户输入或本地时间转为 UTC（例如 JS 用
date.toISOString()，Java 用ZonedDateTime.withZoneSameInstant(ZoneOffset.UTC)），再插入数据库 - 返回给前端的时间，按用户所在时区格式化（不是数据库里“转出来”，而是查出 UTC 后，在应用或前端转）
- 禁止在 SQL 中用
NOW()、CURRENT_TIMESTAMP直接插入——除非确认数据库时区=业务期望时区，且永不变更；更稳妥的是由应用生成 UTC 时间传入
排查与验证不能只看“显示值”
很多问题源于误判“看起来一样”的时间实际不等价：
- 查数据时，用
EXTRACT(EPOCH FROM xxx)（PostgreSQL）或UNIX_TIMESTAMP(xxx)（MySQL）确认底层秒数是否一致 - 对比两个时间前，确保它们已落在同一时区上下文——比如都转成 UTC 再比较，而不是直接比字符串或本地格式
- 上线新时区逻辑前，在测试库中手动改
time_zone参数，验证读写行为是否符合预期
不复杂但容易忽略。关键不在技术多难，而在团队对每个时间字段达成共识，并落实到建表语句、ORM 配置、API 规范里。
