PostgreSQL在时间处理上的能力非常强，但不同日期时间类型以及时区转换之间隐藏着不少容易忽略的细节。很多开发者在建表时随意选择timestamp，结果在跨时区场景下出现了数据不一致。本文从基础函数开始，逐步剖析时区机制，并给出实用的避坑方案。
一、核心日期时间函数与时间类型盘点
PostgreSQL支持多种日期时间相关类型，常见的有date、time、timestamp、timestamptz以及interval。date只存储年月日，time只存储时分秒，timestamp表示不带时区的日期时间，timestamptz等于timestamp with time zone，底层存储的是UTC时间戳，展示时会根据会话时区自动换算。interval专门用于表示时间间隔，例如1 day、3 hours。理解这些类型是后续函数调用的基础。
获取当前时间有多个函数，容易混淆。now()返回当前事务开始的时间，transaction_timestamp()与now()等价；statement_timestamp()返回当前语句开始时间；clock_timestamp()返回真正的墙钟时间，每次调用都不同。current_date返回当前会话时区下的日期，current_time返回当前时间，current_timestamp与transaction_timestamp()等价。下面的查询展示了这些函数的输出差异。
SELECT now(),
transaction_timestamp(),
statement_timestamp(),
clock_timestamp(),
current_date,
current_time,
current_timestamp;date_trunc用于把时间截断到指定精度，比如按月、按天、按小时。extract和date_part可以从时间值中提取年、月、日、小时等部分。例如date_trunc('month', now())会把日期截断到当月第一天零点。这些函数在做统计报表时非常实用。下面示例计算两个时间戳之间的小时差，并截取到周。
SELECT date_trunc('week', now()) AS week_start,
extract(epoch FROM now() - '2024-01-01 00:00:00'::timestamp) AS seconds_diff,
date_part('hour', now()) AS current_hour;二、时区机制：timestamp与timestamptz的核心区别
很多开发者以为timestamptz会额外存储时区信息，实际上不是。timestamptz内部统一用UTC存储，不保存原始的时区标识。当写入一个带时区的时间值时，PostgreSQL会先把它换算成UTC再落盘。读取时，根据当前会话的timezone参数转换为对应时区的本地时间进行展示。而timestamp without time zone不会做任何转换，输入什么就存什么，输出时也原样返回。这是二者最本质的差异。
会话时区可以通过set time zone命令修改，也可以在连接参数中指定。例如设置美国东部时区后，同样的timestamptz值显示结果会变化。AT TIME ZONE操作符则可以把一个时间值转换到指定时区，但要注意输入类型不同结果不同：timestamptz经过AT TIME ZONE会得到一个timestamp without time zone；而timestamp without time zone经过AT TIME ZONE则会得到timestamptz。下面演示这两个方向的转换。
-- 设置会话时区 SET TIME ZONE 'America/New_York'; SELECT now() AS local_now; -- timestamptz转成指定位时区的本地时间（结果是timestamp） SELECT now() AT TIME ZONE 'UTC' AS utc_time_no_tz; -- timestamp不带时区，解释为指定时区的时间（结果是timestamptz） SELECT '2024-06-15 12:00:00'::timestamp AT TIME ZONE 'America/Los_Angeles' AS la_time_with_tz;
时区名称建议使用完整的地域名称，例如America/New_York，而不是缩写如EST。缩写存在语义歧义，且无法正确处理夏令时。PostgreSQL依赖操作系统的时区数据库，能够根据日期自动判断夏令时的起止。比如在America/New_York时区，2024年3月10日凌晨2点之后时钟直接跳到3点，使用带时区计算时不会出现重复或缺失的时刻。在涉及跨时区排程时，最好存储timestamptz并记录事件发生地的时区标识，展示时再转换。
三、常见业务场景与避坑建议
实际项目里建议数据库层一律使用timestamptz存储时间点。应用层在写入时把本地时间带上明确时区信息或直接转为UTC，读取时再把数据库返回的本地显示时间提供给前端。避免在数据库层用timestamp裸存字符串，因为这样会丢失时间语义，导致不同服务器部署后出现偏移。如果业务本身就是固定地区系统，可以在连接参数内统一设置timezone，减少转换步骤。
在where条件中直接对时间列做函数运算，比如date(created_at) = '2024-06-15'，会导致该列上的B-tree索引无法使用，因为需要逐行计算才能比较。更好的写法是使用范围条件：created_at >= '2024-06-15' AND created_at < '2024-06-16'。如果created_at是timestamptz类型，比较会按照会话时区换算，但索引仍然有效。下面示例对比两种查询。
-- 不推荐：函数包裹列 SELECT * FROM orders WHERE date(created_at) = '2024-06-15'; -- 推荐：范围比较，可以使用索引 SELECT * FROM orders WHERE created_at >= '2024-06-15' AND created_at < '2024-06-16';
使用interval做加减时，要注意月份和天数的组合。例如now() + interval '1 month'不会简单加30天，而是根据月份长度自动调整。如果日期是1月31日，加一个月会得到2月28日或29日。这种语义在房租、订阅等周期性业务中非常合适，但如果想要严格的30天，则应该用interval '30 days'。另外，统计周数据时最好确定周是从周一开始还是周日，date_trunc('week', ...)默认以周一为起点，可以使用extract(isodow from ...)来获取ISO工作日编号。
最后总结一下：充分理解PostgreSQL日期时间函数和时区模型，可以避免大多数时间相关的数据错误。建表时优先使用timestamptz，查询时避免在列上套函数，时区设置尽量统一，这样系统在本地和跨地域部署中都能保持准确。
