你的时间戳在骗你
一张火车票教会我的数据库时间存储之道
我在订一张从纽约到芝加哥的火车票时，突然意识到为什么 Postgres 中的时间戳类型如此令人困惑。车票上显示：
- 出发：8:00 AM EST
- 到达：7:30 PM CST
- 历时：11 小时 30 分钟
同一张票上用了三种不同的方式来描述时间。而在数据库中，每一种都需要以不同的方式存储。
没人先问的问题
在 Postgres 中，TIMESTAMP 和 TIMESTAMPTZ 都占用 8 个字节，且具有相同的微秒级精度。那么，为什么非要设计两种类型呢？
因为“现在几点？”完全取决于你想告诉对方什么。
当我在纽约登上那列火车时，我需要知道它在东部时间上午 8:00 出发。这是我需要对齐的车站时钟上的数字。当我的朋友在芝加哥接我时，她需要知道我在中部时间晚上 7:30 到达——那是她的时钟上的数字。而如果我想搞清楚是否有时间看书，我需要知道这是一段 11 个半小时的旅程。
同一列火车，同一段旅程。三种完全不同的时间表达方式。
TIMESTAMPTZ 到底在做什么
关于 TIMESTAMPTZ 有个门槛——而且它和大多数人想的不一样。它并不存储时区。这个名字具有误导性。
它的实际作用是：在存储之前，将你提供的任何时间转换为 UTC；然后在读取时，再将其转换回你当前会话的时区。“TZ”部分指的不是存储，而是转换支持。
假设你在存储那趟火车的出发时间。东京的人查询你的数据库，看到的是 JST 格式的出发时间；伦敦的人看到的是 GMT 格式。每个人看到的都是同一个绝对瞬间，只是用他们配置的时区表达了出来。这对于记录事件非常完美：“这笔付款是什么时候处理的？”或者“这个 API 请求是什么时候发生的？”
但那张火车票呢？你并不希望出发时间仅仅因为有人从不同的时区查询就发生变化。火车在东部时间上午 8:00 出发，就这么简单。这不是一个绝对的时间点——而是一个关于大中央车站的时钟会显示什么的承诺。
存储你的真实意图
对于那段火车旅程，你需要根据不同的目的存储不同的内容：
- 绝对瞬间（
departs_at和arrives_at使用TIMESTAMPTZ） - 显示上下文（
origin_timezone和destination_timezone使用文本类型） - 持续时间（两个瞬间之间的
INTERVAL）
现在，你的应用程序可以像火车票一样运作了：通过将绝对瞬间转换为始发地时区来显示“8:00 AM EST 出发”，通过转换为目的地时区来显示“7:30 PM CST 到达”，并直接从间隔中显示“历时：11h 30m”。
在东京订票的人在每个车站看到的都是当地时间。这才是他们需要知道的信息。
为什么你的航班追踪应用会出错
你有没有注意到，有些航班追踪应用会在飞行途中显示你当前所在位置的时区？比如你正飞在大西洋上空，它显示“当前时间：下午 4:32 GMT”。谁在乎这个？你又不在格林威治，你是在大洋上空 38,000 英尺的某个地方。
你真正想看到的是：
- 起飞后已过去的时间
- 距离到达目的地还剩多长时间
- 降落时当地是几点
这些都不是简单的时区转换。前两个是 间隔（intervals）——是持续时长，而非时间点。最后一个虽然是时区转换，但是针对特定地点的转换，而不是“你当前所在的时区”。
看出来了吗？这里有两个间隔计算（NOW() - actual_departure 和 estimated_arrival - NOW()），以及一个针对特定地点的时区转换（AT TIME ZONE destination_timezone）。你当前所在的系统时区根本不应该参与计算。
什么时候挂钟时间才是你真正需要的
酒店并不关心绝对的时间点。他们关心的是其所在地时钟的读数。
“下午 3:00 后办理入住”并不意味着“UTC 午夜后 15 小时办理入住”。它的意思是“只要我们大堂的时钟显示 3:00 PM，你就可以办理入住”。如果你的服务器在弗吉尼亚，但酒店在巴黎，你仍然希望这条规则在巴黎时间下午 3:00 触发。
TIME 类型（不含日期或时区）表达的正是这种含义：“时钟上的一个读数”。将其与时区文本字段（如 “Europe/Paris”）配合使用，无论你的服务器部署在哪里，你都可以执行基于挂钟时间的策略。但同时，你仍需要 TIMESTAMPTZ 列来记录特定客人的实际入住和退房时间——这些才是后端需要追踪的绝对瞬间。
日历难题
我设置了一个上午 9:00 的重复提醒：“回顾每日优先级”。我希望这个提醒在无论我身在何处的上午 9:00 响起。如果我在旅行，它仍应在当地时间上午 9:00 触发。
但我还有一个日历事件：“上午 10:00 EST 团队站会”。我远在柏林的同事看同一个事件时，需要看到“下午 4:00 CET”。同一个会议，不同的显示时间，因为这是一个我们所有人都要同时参加的绝对瞬间。
两种不同类型的事件，需要两种不同的存储策略。会议使用 TIMESTAMPTZ。提醒则使用 TIME 加上我当前的时区设置。不要试图强行将两者塞进同一个字段。
生产环境中会出故障的地方
即便选对了类型，精度问题也可能让你栽跟头。Postgres 存储微秒：10:00:00.123456。而 JavaScript 的 Date 对象使用的是毫秒：10:00:00.123。
因此，下面这个查询可能会莫名其妙地返回空结果：
SELECT * FROM orders WHERE created_at = '2026-01-15 10:00:00.123';数据库里存的是 10:00:00.123456，而你的代码传过去的是 10:00:00.123。取决于你的驱动程序如何处理，这两者可能无法匹配。
永远不要对时间戳使用精确等值查询。使用范围查询，或者更好的做法是——根本不要通过创建时间戳来查找记录。请使用正式的唯一约束或幂等键。
实践准则
默认使用 TIMESTAMPTZ。 犹豫不决时，就选 TIMESTAMPTZ。它能自动处理多区域部署、夏令时以及未来的时区变更。它的存储大小与 TIMESTAMP 相同，没有任何性能损失。
单独存储上下文。 如果你需要同时显示“东部时间上午 8:00 出发”和实际发生的瞬间，请将 TIMESTAMPTZ 和 origin_timezone（原始时区）存为两个独立的列。不要试图把所有信息都塞进一个字段。
考虑时间间隔（Interval）。 许多与时间相关的需求本质上是关于时长，而非时刻。“这笔交易挂起了多久？”“什么时候过期？”请使用 INTERVAL 操作，而不是时区转换。
全链路运行 UTC。 你的服务器应该设置为 UTC。你的数据库会话默认也应该是 UTC。只在向用户展示时才转换为当地时区，且前提是你明确知道哪个时区才是关键。
强制要求客户端提供时区信息。 如果客户端发送 2026-01-15T10:00:00 且不带偏移量，直接拒绝。强制要求符合 ISO-8601 格式，带上 Z 或明确的偏移量（如 -05:00）。不要靠猜。
强制执行良好的默认设置
如果 TIMESTAMPTZ 是你的默认选择（也理应如此），可以考虑在数据库层面强制执行。虽然写个触发器来拒绝 TIMESTAMP WITHOUT TIME ZONE 列听起来有些极端，但在创建模式（Schema）时拦截“忘了加 TZ”的情况，总好过半年后有人新建表漏掉字段导致你去排查 Bug。
那张火车票教会我的事
数据库中的时间处理之所以难，并不是因为时间戳本身复杂。而是因为我们通常试图在一个字段里存储多个关注点，或者根本没想清楚到底要给用户展示什么。
那张火车票的做法是正确的：出发时间采用始发地时区，到达时间采用目的地时区，而时长则完全是另一回事。三份不同的信息，各自都有其存在的意义。
你的数据库也可以做到这一点。将绝对时刻存为 TIMESTAMPTZ。将显示上下文（时区、地点）存为独立的列。对时长使用 INTERVAL 类型。需要时让 Postgres 处理转换，但要明确哪个时区对应哪个用途。
大多数情况下，这意味着全链路 TIMESTAMPTZ 和 UTC，仅在展示层进行时区转换。但当你需要处理挂钟时间或周期性调度时，TIMESTAMP 或 TIME 类型正是为此而生。
关键在于搞清楚你试图回答的是什么问题：“这事儿什么时候发生的？”对比“我该几点到那儿？”对比“这要花多久？”这些都是关于时间的不同问题，通常需要不同的存储策略。
先思考用户需要看到什么，然后存储能让你准确呈现这些信息的数据。