AT TIME ZONE 仅做时区偏移转换，不实现业务“准时”逻辑；它将无时区时间解释为某地本地时间再转UTC，或转换带时区时间的显示形式，本质是类型转换而非调度。
AT TIME ZONE 不能直接用于任意时区间“准时化”转换——它只做时区偏移解释或转换，不处理业务逻辑中的“准时”含义（比如“每天早上9点本地时间触发”需额外建模）。
AT TIME ZONE 的本质是类型转换，不是时间调度
PostgreSQL 的 AT TIME ZONE 作用对象是 TIMESTAMP WITHOUT TIME ZONE 或 TIMESTAMP WITH TIME ZONE，它不改变时间点的物理意义，只改变其表示方式：
-
TIMESTAMP WITHOUT TIME ZONE→ 被解释为某时区的本地时间，再转成 UTC 或目标时区的带时区时间 -
TIMESTAMP WITH TIME ZONE→ 被转成目标时区的等效带时区时间（底层统一为 UTC）
例如：SELECT '2024-06-01 09:00'::TIMESTAMP WITHOUT TIME ZONE AT TIME ZONE 'Asia/Shanghai' 把字面值当作北京时间 9 点，转成 UTC 时间 2024-06-01 01:00:00+00；反过来用 AT TIME ZONE 'America/New_York' 得到的是同个时刻在纽约的表示（2024-06-01 21:00:00-04），不是“把上海 9 点映射成纽约 9 点”。
“每天 9 点本地时间”必须拆解为两步：存储 + 计算
业务上常说的“准时”，比如“用户设置每日 9:00 推送”，实际依赖两个独立信息：用户所在时区 + 本地时间点。数据库里不能只存一个 TIMESTAMP 就自动满足这个语义。
- 推荐表结构：
user_id、local_time（TIME WITHOUT TIME ZONE）、timezone（TEXT，如'Europe/London'） - 查询当天应触发的时间（UTC）：
SELECT (CURRENT_DATE + u.local_time) AT TIME ZONE u.timezone AT TIME ZONE 'UTC' AS trigger_at_utc FROM users u WHERE u.id = 123;
- 注意顺序：
AT TIME ZONE是左结合，t AT TIME ZONE tz1 AT TIME ZONE tz2等价于(t AT TIME ZONE tz1) AT TIME ZONE tz2，中间结果是TIMESTAMP WITH TIME ZONE
常见错误：混淆“时间点”和“时间表达”
以下写法看似合理，实则危险：
-
SELECT created_at AT TIME ZONE 'Asia/Shanghai' FROM events—— 如果created_at已是TIMESTAMP WITH TIME ZONE（比如来自应用层传入的2024-06-01 01:00:00+00），这句只是把它转成北京时间显示（2024-06-01 09:00:00+08），没问题；但若created_at是无时区类型，就默认按服务器时区解释，可能出错 - 用
AT TIME ZONE做聚合分组时忽略 DST 切换：比如按“纽约当地时间日期”分组，(event_time AT TIME ZONE 'America/New_York')::DATE在 3 月第二个周日会漏掉一小时（钟拨快），导致那天的 2:00–2:59 事件被归入错误日期 - 跨时区比较用错基准：想查“东京用户下单早于伦敦用户”，不能直接比
order_time AT TIME ZONE 'Asia/Tokyo'和order_time AT TIME ZONE 'Europe/London'，必须先统一转 UTC 或同一目标时区
真正难的不是语法，而是厘清“这个时间值代表什么”：是服务器记录时刻？用户主观感知时刻？还是某个政策生效的法定时刻？每种都需要不同的字段设计和转换路径。时区名要用 IANA 标准（'Australia/Sydney' 而非 'AEST'），否则夏令时会失效。
