INTERVAL 是最自然的写法，但需严格区分 DAY TO SECOND 和 YEAR TO MONTH 两类；后者加月份按日历月处理（如1月31日+1月得2月29日），且不支持直接与 TIMESTAMP WITH TIME ZONE 运算，应优先用 ADD_MONTHS 或显式时区转换。
直接用 interval 是最接近自然语义的写法，但必须分清 day to second 和 year to month 两个家族，混用不报错却结果错得离谱。
为什么 SYSDATE + INTERVAL '1' MONTH 有时跳到月底？
Oracle 对 INTERVAL '1' MONTH 的处理是“日历月”语义：它不加 30 天，而是把月份字段 +1，再按目标月天数自动截断。比如 2024-01-31 + INTERVAL '1' MONTH 得到的是 2024-02-29（闰年），不是 2024-03-02。
- 这种行为和
ADD_MONTHS()一致，但ADD_MONTHS()更明确、更常用 -
INTERVAL '1' MONTH在 PL/SQL 中不能用于TIMESTAMP WITH TIME ZONE直接运算，会隐式转成TIMESTAMP丢掉时区信息 - 若需跨时区保持语义（如“北京时间 3 月 15 日 10:00 加 1 个月”），必须先用
AT TIME ZONE统一时区再算
INTERVAL YEAR TO MONTH 不能和 TIMESTAMP 直接相加
常见错误是写 ts + INTERVAL '1-6' YEAR TO MONTH，表面看没问题，但 Oracle 实际执行时会尝试把 INTERVAL YEAR TO MONTH 当作年份字面量去解析，触发 ORA-01841 ——尤其在动态拼 SQL 或绑定变量场景下。
- 正确做法是先转时区：
FROM_TZ(ts, 'UTC') + INTERVAL '1-6' YEAR TO MONTH - 或更稳妥地改用
ADD_MONTHS(ts, 18)（1 年 6 个月 = 18 个月） -
ADD_MONTHS()不接受INTERVAL类型参数，只认数字，所以ADD_MONTHS(ts, -3)可以，但ADD_MONTHS(ts, INTERVAL '3' MONTH)会报错
NUMTODSINTERVAL 比字符串 INTERVAL 更可靠
写 INTERVAL '30' MINUTE 看似简单，但一旦分钟值带小数（如 30.5 分钟），就必须用 NUMTODSINTERVAL(30.5, 'MINUTE')，否则报 ORA-01867。
-
NUMTODSINTERVAL(n, unit)支持小数，单位可为'DAY'、'HOUR'、'MINUTE'、'SECOND' - 字符串形式的
INTERVAL要求严格匹配精度声明，比如INTERVAL '1.234567' SECOND(6)才合法；少一位就报错 - 性能上，
SECOND(6)比SECOND(0)多约 5% CPU 开销，纯天/小时级运算建议降精度
时区敏感场景下，INTERVAL DAY TO SECOND 是绝对时长
两个 TIMESTAMP WITH TIME ZONE 相减得到的 INTERVAL DAY TO SECOND，是 UTC 时间轴上的真实秒数差。比如 TO_TIMESTAMP_TZ('2026-04-19 10:00:00 Asia/Shanghai', ...) 减 TO_TIMESTAMP_TZ('2026-04-19 09:00:00 America/New_York', ...)，结果是 +000000001 02:00:00.000000000（1 天 2 小时），而非“当地时间过了几小时”。
- 若要计算“当地时间经过的天数”，必须先统一时区：
(ts1 AT TIME ZONE 'UTC') - (ts2 AT TIME ZONE 'UTC') - 直接对不同时区的
TIMESTAMP WITH TIME ZONE加INTERVAL DAY TO SECOND是安全的，因为它是绝对偏移 - 但加
INTERVAL YEAR TO MONTH前，务必确认两个值是否已归一到同一本地时区，否则日历逻辑会错乱
真正容易被忽略的是：Oracle 从不强制你选对类型——TIMESTAMP 加 INTERVAL YEAR TO MONTH 看似能跑，但底层悄悄做了隐式转换，结果取决于当前 NLS 设置和上下文，线上环境可能和开发库表现不一致。
