TIMESTAMP直接加INTERVAL YEAR TO MONTH不会报语法错误但结果不可控，因其无时区信息，Oracle无法按日历规则正确处理跨月（如1月31日+1月可能得2月31日），须转为TIMESTAMP WITH TIME ZONE或用ADD_MONTHS()。
为什么直接对TIMESTAMP加INTERVAL YEAR TO MONTH会出错
因为TIMESTAMP类型不带时区信息，Oracle无法确定“1个月”该按哪种日历规则解释——是固定30天？还是按实际月份长度（如1月31天、2月28/29天）？更关键的是，它不知道起始时间属于哪个时区，跨月计算时可能落到不存在的日期（比如TIMESTAMP '2026-01-31 10:00:00' + INTERVAL '1' MONTH在某些版本里变成2月31日，触发ORA-01841）。这不是语法错误，但结果不可控。
-
TIMESTAMP只能安全加INTERVAL DAY TO SECOND（如INTERVAL '1' HOUR、INTERVAL '30' DAY） -
INTERVAL YEAR TO MONTH必须搭配TIMESTAMP WITH TIME ZONE或DATE使用 -
DATE虽能直接加INTERVAL YEAR TO MONTH，但会丢失秒级精度（自动归零）
怎么把普通TIMESTAMP升级成带时区的类型
核心是显式锚定上下文，不能依赖会话时区隐式转换。用FROM_TZ最稳妥，它把时间值和指定时区绑定成一个完整逻辑单元：
FROM_TZ(ts, 'UTC') + INTERVAL '3' MONTH
或者用AT TIME ZONE（效果等价，但语义更清晰）：
ts AT TIME ZONE 'Asia/Shanghai' + INTERVAL '3' MONTH
- 避免用
SESSIONTIMEZONE作为参数——会话时区可能被ALTER SESSION临时改掉，导致同一段代码在不同连接里行为不一致 - 时区名推荐用区域名（如
'Asia/Shanghai'），比偏移量（如'+08:00'）更可靠，能自动处理夏令时 - 如果原始
ts来自用户输入且已知其本地含义，就用那个本地时区；如果只是系统内部时间戳，统一用'UTC'最安全
ADD_MONTHS()比直接加INTERVAL更靠谱吗
是的，尤其当你只关心日历月数增减，不涉及时区转换时。ADD_MONTHS()专为日历运算设计，内部会做日期合法性校验（比如1月31日加1个月 → 2月28日或29日），且对TIMESTAMP也支持（保留秒和亚秒精度）：
ADD_MONTHS(ts, 6) -- 正向加6个月
ADD_MONTHS(ts, -2) -- 减2个月，注意：不能传负的INTERVAL字面量
-
ADD_MONTHS()不接受INTERVAL类型参数，只能传整数，所以动态月数要拼成变量或表达式 - 它不处理时区，所有计算都在
TIMESTAMP值本身上进行，适合纯业务逻辑（如账期计算、有效期推算） - 如果后续还要做时区转换，先用
ADD_MONTHS()算完，再用FROM_TZ转成带时区类型
查询时如何避免时区显示混乱
用TO_CHAR格式化输出时，TIMESTAMP WITH TIME ZONE的时区信息默认会参与格式化，但NLS_TIMESTAMP_TZ_FORMAT可能没设好，导致只显示偏移量不显示区域名。最稳的方式是显式指定格式模型：
TO_CHAR(ts_tz, 'YYYY-MM-DD HH24:MI:SS TZR')
其中TZR代表时区区域名（如Asia/Shanghai），TZD代表夏令时缩写（如CST）。
- 不要依赖
SELECT ts_tz FROM ...裸查——不同客户端（如DBeaver、SQL*Plus）对时区字段的默认渲染差异很大 -
TIMESTAMP WITH LOCAL TIME ZONE列查出来永远是当前会话时区的时间，但存进去时已被转成数据库时区，容易误判原始值 - 如果应用层需要统一时区展示，建议所有时间戳入库前都转成
TIMESTAMP WITH TIME ZONE并固定用'UTC'，查出来再按需转换
真正麻烦的不是语法写不对，而是你以为加了个INTERVAL '1' MONTH就万事大吉，结果上线后发现每月最后一天的数据总错位一天——那大概率是TIMESTAMP没升到带时区类型，或者ADD_MONTHS()没用对。
