Oracle的ADD_MONTHS函数将2024-02-29加1个月返回2024-03-01，是设计行为而非bug；仅当源日期为当月最后一天时结果才取目标月最后一天，否则按日偏移计算，需手动兜底处理2月29日场景。
ADD_MONTHS遇到2月29日会变成3月1日，不是bug是设计
Oracle的ADD_MONTHS对月末日期有特殊规则：当源日期是某月最后一天，结果也强制取目标月最后一天；但若源日期是2月29日（闰年），而目标月没有29日，它不会“回退到28日”，而是直接跳到3月1日。这不是计算错误，是Oracle文档明确定义的行为。
比如：ADD_MONTHS(DATE '2024-02-29', 1) 返回 2024-03-01，而非 2024-02-28 或 2024-03-01以外的任何值。
- 只有源日期是「该月最后一天」时，
ADD_MONTHS才保证结果也是目标月最后一天（如2024-02-29→2024-03-31） -
2024-02-28不是2月最后一天（29日才是），所以ADD_MONTHS(DATE '2024-02-28', 1)=2024-03-28，严格按日偏移 - 这个逻辑在跨年、跨闰年时同样生效，比如
ADD_MONTHS(DATE '2024-02-29', 12)=2025-03-01
想让2月29日“安全下落”到2月28日？得手动兜底
如果业务要求所有2月日期加月份后仍留在2月（即2月29日→2月28日，2月28日→2月28日），不能依赖ADD_MONTHS原生行为，必须检测并修正。
常用做法是用LAST_DAY + 条件判断：
SELECT
CASE
WHEN EXTRACT(MONTH FROM d) = 2 AND EXTRACT(DAY FROM d) IN (28, 29)
THEN LAST_DAY(ADD_MONTHS(TRUNC(d, 'MM'), n))
ELSE ADD_MONTHS(d, n)
END AS safe_date
FROM (SELECT DATE '2024-02-29' AS d, 1 AS n FROM DUAL);
-
TRUNC(d, 'MM')把日期归到当月1日，再ADD_MONTHS避免29日触发跳变 -
LAST_DAY(...)确保结果是目标月最后一天（即平年2月→28日，闰年2月→29日） - 只对2月28/29日做特殊处理，其他日期走原逻辑，不影响性能和语义
用EXTRACT判断闰年不如直接查LAST_DAY是否为29日
别写MOD(EXTRACT(YEAR FROM d), 4) = 0 AND ...来判断闰年——太重，且Oracle不支持在SQL中完整实现格里高利历闰年规则（比如整百年需被400整除）。更简单可靠的方式是看2月最后一天是不是29日：
SELECT d, LAST_DAY(ADD_MONTHS(TRUNC(d, 'YY'), 1)) AS feb_end_next_year FROM (SELECT DATE '2024-01-01' AS d FROM DUAL);
- 如果
feb_end_next_year = DATE '2025-02-28'，说明2025年不是闰年 - 这个技巧绕过年份计算，直接用Oracle内置日期函数验证，100%准确
- 在需要动态决定是否“保留29日”的场景（如养老金按闰年多算一天），比手工判闰年更安全
批量处理时注意NLS_DATE_FORMAT可能掩盖问题
如果会话NLS_DATE_FORMAT设为'YYYY-MM-DD'，ADD_MONTHS(DATE '2024-02-29', 1)返回的2024-03-01看起来像“正常日期”，但实际已偏离预期月末逻辑。尤其在报表或ETL中，这种隐式转换容易导致月末统计漏掉1天。
- 执行前确认
SELECT SYSDATE FROM DUAL返回格式是否含时分秒，避免截断误判 - 关键日期字段建议显式用
TO_CHAR(date_col, 'YYYY-MM-DD HH24:MI:SS')输出，暴露真实值 - 在存储过程里处理月末逻辑时，优先用
DATE类型运算，别转成字符串再拼接
最麻烦的不是函数怎么写，而是团队里有人默认“2月29日加一个月还是2月”，却没意识到Oracle根本没这个语义。上线前务必用2024-02-29、2025-02-28、2023-02-28三组数据跑一遍边界测试。
