PostgreSQL日期时间字段类型选择指南

前几天用KingFusion低代码平台搭MES系统，后端数据库选的是PG。结果在存一条日期时间数据时报了错，让我立刻意识到——字段类型没选对。于是顺手把PostgreSQL里跟日期时间相关的数据类型梳理了一遍，索性分享出来。

如果只是要存像 2026-05-18 11:05:17 这种“日期+时间”的格式，其实PostgreSQL官方的推荐非常明确：用 timestamp without time zone 类型，平时可以简写成 timestamp。这基本就是最稳妥、最通用的方案。

一、首选：timestamp without time zone

1. 它能存什么

• 内容：精确到微秒的日期和时间，格式是 YYYY-MM-DD HH:MM:SS.ffffff
• 大小：8字节
• 范围：从公元前4713年到公元294276年，几乎够用几辈子的数据
• 精度：默认到微秒（6位小数），也可以手动指定精度，比如用 timestamp(3) 只到毫秒

2. 建表时怎么写

CREATE TABLE your_table (
    id serial PRIMARY KEY,
    create_time timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
    update_time timestamp
);

注意这里用了 CURRENT_TIMESTAMP 作为默认值，这样每次插入时自动记录创建时间，省心又标准。

3. 插入数据

-- 直接用字符串，PG会自动转换
INSERT INTO your_table (create_time) VALUES ('2026-05-18 11:05:17');

-- 也可以用标准函数
INSERT INTO your_table (create_time) VALUES (NOW());
INSERT INTO your_table (create_time) VALUES (CURRENT_TIMESTAMP);

三种写法都行，实际开发里用 CURRENT_TIMESTAMP 最符合SQL标准，跨数据库迁移时也少些麻烦。

二、其他类型怎么选

类型	存什么	适用场景	不建议用在哪
timestamp without time zone	本地日期+时间，没有时区	所有用户在同一时区，只看本地时间的项目，比如国内单区域系统	跨时区、需要处理全球用户时间的场景
timestamp with time zone（简称 timestamptz）	UTC时间戳+时区偏移	全球化系统、跨时区应用，需要精确记录事件发生的时间点	只关心本地时间、不需要时区转换的时候
date	仅日期，比如 YYYY-MM-DD	只需要日期的情况，比如生日、订单日期	需要精确到时分秒的场景
time without time zone	仅时间，比如 HH:MM:SS	每日定时任务、只关心具体时间的场景	需要完整日期时间的场景
varchar/text	字符串形式的日期时间	千万别这么干	所有需要计算、排序、索引的场景

三、注意事项

1. 永远别用 varchar 存日期时间

这是最常见、也最痛的坑。用字符串存时间，会导致：

• 用不了 DATE_TRUNC、AGE、EXTRACT 这些强大的时间函数
• 排序会混乱——字符串排序会把 2026-05-18 排在 2026-05-2 后面，因为字符比较是按位来的
• 索引基本废掉，查询性能直线下降
• 数据格式容易五花八门，脏数据迟早来找你

2. timestamp 和 timestamptz 的核心区别

• 存的方式：两个类型都占8字节，但 timestamptz 实际存储的是UTC时间戳，不是本地时间
• 显示方式：timestamptz 会根据数据库或客户端的时区自动转换显示，而 timestamp 就是原样输出
• 选哪个：国内项目只在单时区运行，timestamp 完全够用；如果你的应用要面向全球用户，那统一用 timestamptz 存UTC时间更靠谱

3. 关于 datetime 类型

PostgreSQL里确实有 datetime 这个类型，但千万别被它迷惑——这是为了兼容MySQL才保留的一个别名，本质上就是 timestamp without time zone。官方推荐直接写 timestamp，清晰明了。

四、最佳实践

1. 要存 2026-05-18 11:05:17 这种格式：用 timestamp without time zone，简单直接
2. 业务涉及跨时区：用 timestamp with time zone，统一管好UTC时间
3. 只需要日期：用 date，省空间、更清晰
4. 默认值推荐用 CURRENT_TIMESTAMP，SQL标准、兼容性好
5. 避免用 varchar、text 或者 datetime 别名，踩过坑的都知道有多疼

字段类型选对了，往后省心不只一点半点。希望这份梳理对你有用。