嘿，这个问题我之前也碰到过，核心原因其实是Oracle对两位年份的解析规则搞的鬼！

为什么1940年的计算会出问题？ #

Oracle默认情况下，两位年份的解析范围是1950-2049。也就是说，当你直接写'11/01/40'时，Oracle会自动把它当成2040年11月1日来处理——这可是未来的日期啊！所以months_between(sysdate, '11/01/40')算出来的是当前日期到2040年的月份差，结果自然是负数（比如现在是2025年的话，刚好是-19左右）。而1950年及以后的两位年份（比如'11/01/50'）会被正确解析成1950年，所以计算就正常了。

靠谱的解决方法 #

这里有几个实用的方案，按推荐程度排序：

1. 直接用四位年份（最稳妥，零歧义） #

输入日期时直接写全四位年份，彻底避免解析错误：

select months_between(sysdate, '11/01/1940') from dual;

更严谨的写法是用TO_DATE明确指定格式，防止数据库默认格式变化影响结果：

select months_between(sysdate, TO_DATE('11/01/1940', 'MM/DD/YYYY')) from dual;

2. 用RR格式掩码解析两位年份 #

如果你必须用两位年份，可以用Oracle的RR格式掩码来智能判断世纪：

• 当当前年份后两位在00-49时，输入的00-49会解析为2000-2049，50-99解析为1950-1999
• 当当前年份后两位在50-99时，输入的00-49会解析为1900-1949，50-99解析为2050-2099

针对你的1940年场景，用RR就能正确解析：

select months_between(sysdate, TO_DATE('11/01/40', 'MM/DD/RR')) from dual;

3. 临时修改会话的日期格式 #

如果需要在当前会话里统一处理这类两位年份，可以修改会话级的日期格式，加入RR掩码：

ALTER SESSION SET NLS_DATE_FORMAT = 'MM/DD/RR';

之后再执行你原来的查询，'11/01/40'就会被正确解析成1940年了：

select months_between(sysdate, '11/01/40') from dual;

注意：这个修改只在当前会话生效，关掉重新打开会话就会恢复默认设置哦。

先验证日期解析是否正确 #

你可以先跑个查询确认日期解析对不对，比如：

select TO_DATE('11/01/40', 'MM/DD/RR') as parsed_date from dual;

如果返回的是1940-11-01，那后面计算年龄就没问题啦！

内容的提问来源于stack exchange，提问作者Root163