企业官网建设流程全解析

RR 日期格式这几个字，第一次撞见通常是在一段老 SQL 或者一条看不懂的报错里。很多人扫一眼就过去了，觉得不就是个日期格式嘛，跟 YYYY 差不多。真等到某天导进来一批数据，年份集体错了一百年，才发现这玩意儿里面有规则，而且规则还不止一套。我先把话说明白：RR 是 Oracle 数据库TO_DATE/TO_CHAR格式串里的一个年份格式元素，专门处理两位年份，靠一套固定阈值把98推回1998、把24推回2024。它解决的是历史系统里年份只存两位、解析时世纪不明的问题。但它不是万能钥匙，阈值到了会翻转，跟别的语言规则也不一样。这篇东西适合三类人看：正在维护老系统的 DBA 和开发、要给历史数据做迁移清洗的工程师、以及被ORA-01839这类报错卡住过的同学。下面从算法讲到实例，再讲到生产环境怎么排查，尽量把能直接抄的部分都写出来。

1. RR 到底是什么：一条藏在默认配置里的年份推断规则

先说结论，RR 不是一个"日期类型的格式"，它是格式串里的一个元素，作用范围只在年份那一段。你写TO_DATE('98-06-15','RR-MM-DD')，RR 负责把98变成四位数年份，剩下的月日原样解析；你写TO_CHAR(sysdate,'RR')，它输出当前年份的后两位，跟YY输出完全一样。也就是说，RR 真正有"算法"的地方只在解析方向（字符串转日期），格式化方向它没有任何特殊行为。这一点很多人搞混，以为TO_CHAR用 RR 会有什么魔法，其实不会。

1.1 两位年份这笔老账是怎么欠下的

上世纪七八十年代，磁盘和内存贵得离谱，一个日期字段存19980615要 8 个字节，存980615只要 6 个，乘以几百万行就是实实在在的成本。于是大量系统约定俗成只用两位年份，界面显示、文件交换、报表导出全走两位。当时没人觉得有问题——毕竟大家默认这套系统撑不到 2000 年。结果撑到了。

到了世纪之交，麻烦出现了：字符串01到底是 1901 还是 2001？解析器必须有办法判断。最粗暴的方案是硬编码一个世纪，比如全部当成 1900 年代，那新数据就全错了；稍微聪明一点的做法是引入一个推断规则，根据"现在是什么时候"来猜"这个两位年份属于哪个世纪"。RR 就是这类规则里的一种，而且是被写进数据库内核、还做成了默认配置的那种。

顺便说一句，Oracle 的默认NLS_DATE_FORMAT在很多版本和很多安装环境下是DD-MON-RR。这意味着你可能一直在用 RR，只是没意识到。你在 SQL Developer 或者 SQL*Plus 里直接敲SELECT sysdate FROM dual;，看到的那个15-3月-24形式，背后走的就是 RR。所有形如WHERE create_time > '24-01-01'的隐式转换，也都受这套规则支配。

1.2 YY 和 RR 的分工：一个照抄，一个推断

把这两个元素放在一起对比最清楚。假设当前系统时间是 2024 年 3 月。

看出来了吧，YY 的逻辑简单到近乎危险：它不管你输入什么，一律往当前世纪上套。在当前是 2024 年的前提下，YY解析98会得到 2098 年——一个还没到来的年份。如果这批数据是历史订单，那就等于把 1998 年的单子全扔到了 74 年后。RR 至少还会往回看一眼，把 98 归到 1998。

这就是为什么老系统里大量格式串写的是RR而不是YY：写代码那年头，大家都是奔着"能正确解析 19xx 和 20xx 混合数据"去的，RR 是当时的最优解。

1.3 为什么现在还要懂它

有人会说，都什么年代了，谁还用两位年份。现实是：银行核心系统、老 ERP、制造业 MES、医院 HIS，这些系统里躺着大量VARCHAR2(6)存YYMMDD的表；批量接口的文件格式定死了就是两位年份，改一版要走半年流程；甚至有些新写的代码，因为在老库上跑，NLS_DATE_FORMAT还是DD-MON-RR，一不留神就踩进去。

我在一个数据迁移项目里见过更典型的场景：源端是二十多年前的老系统，导出文件里日期全是YYMMDD；目标端建表时字段是DATE类型，导入脚本图省事写了TO_DATE(:1,'YYMMDD')。跑完一看，2019 年之后的单据全部变成了 2119 年、2120 年，报表排序直接乱掉，财务对账差了整整一百年。改成RRMMDD之后，绝大部分数据对了，但 1950 到 1968 年之间的历史单据又错了——这是后话，第 4 节会展开讲。

2. 算法拆解：50 这条线到底是划在哪里的

RR 的核心就一个阈值：50。输入的两位年份小于 50 归一组，大于等于 50 归另一组，然后结合"当前年份处在半世纪的前半段还是后半段"来决定世纪。听起来绕，画成表就一目了然。

2.1 四象限判定表

设C= 当前年份的后两位（2024 年时C = 24），I= 输入字符串里的两位年份。

这张表有个非常实用的简化版本：只要你的系统跑在 2000 年到 2049 年之间（绝大多数系统都是），规则就退化成一句话——

00到49一律归 20xx，50到99一律归 19xx。

记住这一句，日常 99% 的场景够用了。完整的四象限表是留给"系统要跨到 2050 年"这种长期问题的，第 2.3 节细说。

再补一个细节：这个判断只发生在输入是两位年份的时候。如果你给的是TO_DATE('1998-06-15','RR-MM-DD')，输入本身就是四位，RR 不会再去猜，直接按四位走。实测在多数版本里 RR 对四位输入的表现等同于 YYYY，但不要依赖这个行为——不同版本、不同分隔符组合下的解析容错不一样，混着写迟早出问题。规范做法是：格式串和输入字符串的位数严格对应，两位就两位，四位就四位。

2.2 把 RR 手写一遍：两个语言版本的实现

理解了规则，自己实现一遍是最牢的记忆方式，也是排查问题时能拿来做交叉验证的工具。

Python 版本：

def rr_to_year(yy: int, now_year: int) -> int: """按 Oracle RR 规则把两位年份还原成四位年份""" century = (now_year // 100) * 100 # 当前世纪基点，2024 -> 2000 now_yy = now_year % 100 # 当前年份后两位，2024 -> 24 if yy < 50: # 低年份组：当前处在世纪前半段就归本世纪，否则归下一世纪 return century + yy if now_yy < 50 else century + 100 + yy else: # 高年份组：当前处在世纪前半段就归上一世纪，否则归本世纪 return century - 100 + yy if now_yy < 50 else century + yy # 验证 for y in [0, 24, 49, 50, 99]: print(y, '->', rr_to_year(y, 2024)) # 0 -> 2000 # 24 -> 2024 # 49 -> 2049 # 50 -> 1950 # 99 -> 1999

Oracle 侧的 PL/SQL 版本，适合在不能改库、只能在应用层做校验的场景里用：

CREATE OR REPLACE FUNCTION f_rr_year( p_yy IN VARCHAR2, p_base_year IN NUMBER DEFAULT NULL ) RETURN NUMBER IS l_base NUMBER := NVL(p_base_year, TO_NUMBER(TO_CHAR(SYSDATE, 'YYYY'))); l_cent NUMBER := TRUNC(l_base / 100) * 100; l_now NUMBER := MOD(l_base, 100); l_yy NUMBER := TO_NUMBER(p_yy); BEGIN IF l_yy < 50 THEN IF l_now < 50 THEN RETURN l_cent + l_yy; ELSE RETURN l_cent + 100 + l_yy; END IF; ELSE IF l_now < 50 THEN RETURN l_cent - 100 + l_yy; ELSE RETURN l_cent + l_yy; END IF; END IF; END;

写这个函数最大的价值不是拿来用，而是拿来对拍。你可以把库里的TO_DATE(x,'RR')结果和f_rr_year(x)的结果做一次全量比对，如果 100 个值全对，说明你对规则的理解和数据库实现完全一致；只要有一个不一致，立刻就能定位到边界条件。

2.3 一个必须知道的事实：这条规则每 100 年翻转一次

这是 RR 最阴险的地方，也是各类文档里最少提的一点。

假设你的系统要长期运行。当前是 2024 年，49解析成 2049，50解析成 1950，一切正常。到了 2050 年 1 月 1 日，C从 49 变成 50，四象限的判定翻面了：

也就是说，同一份数据、同一段代码，在 2049 年 12 月 31 日和 2050 年 1 月 1 日跑出来的结果整体差 100 年。这不是 bug，这是规则设计的必然。

RR 设计的隐含假设是："两位年份迟早会被淘汰，这套规则只需要管用几十年"。它把有效区间锁定在[当前世纪基点 - 50, 当前世纪基点 + 49]这个 100 年宽的窗口里，过了窗口就翻。所以任何打算活过 2050 年的系统，就不能把年份解析托付给 RR。这不是危言耸听——现在写下的代码，跑二十几年完全正常，那时候再改就是全表数据重算。

真正稳妥的做法只有一条：存储层用四位年份，展示层想怎么显示都行。RR 只作为解析历史遗留数据的过渡手段存在。

3. 实例演示：把 00 到 99 全部跑一遍

理论说再多不如跑一把。下面这段 SQL 可以直接在任何 Oracle 库里执行，一次性生成完整的 00–99 映射表。

3.1 一条 SQL 生成完整对照表

-- 先固定会话的日期显示格式，避免输出被 NLS 影响 ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS'; SELECT TO_CHAR(LEVEL - 1, 'FM00') AS 输入两位年, TO_CHAR(TO_DATE(TO_CHAR(LEVEL-1,'FM00')||'-01-01','RR-MM-DD'),'YYYY') AS RR结果, TO_CHAR(TO_DATE(TO_CHAR(LEVEL-1,'FM00')||'-01-01','YY-MM-DD'),'YYYY') AS YY结果 FROM DUAL CONNECT BY LEVEL <= 100 ORDER BY LEVEL;

在 2024 年执行，输出一百行。挑关键节点看：

这张表可以留在项目文档里。以后谁再问"为什么这条数据年份不对"，直接甩表过去，比解释半天规则快得多。

注意：上面这段 SQL 依赖当前系统时间，换一天执行结果不变（年份没跨），但换一年执行，边界会移动。想在测试环境验证 2050 年的行为，可以借助ALTER SESSION或者直接在f_rr_year里传p_base_year => 2050，不要真去改服务器时间——生产库上动系统时间是高危操作，会影响审计、序列、定时任务一大堆东西。

3.2 几个典型解析实例

固定会话格式之后，逐个跑一遍会更直观：

-- 例 1：常规历史日期 SELECT TO_DATE('98-06-15','RR-MM-DD') FROM DUAL; -- 结果：1998-06-15 00:00:00 -- 例 2：常规近期日期 SELECT TO_DATE('24-03-08','RR-MM-DD') FROM DUAL; -- 结果：2024-03-08 00:00:00 -- 例 3：分水岭 SELECT TO_DATE('50-01-01','RR-MM-DD') FROM DUAL; -- 结果：1950-01-01 00:00:00 -- 例 4：反向格式化，RR 与 YY 输出一致 SELECT TO_CHAR(DATE '1998-06-15','RR-MM-DD') AS a, TO_CHAR(DATE '1998-06-15','YY-MM-DD') AS b FROM DUAL; -- a = 98-06-15，b = 98-06-15，完全相同

这里要说清楚一个常见误解：TO_CHAR里写 RR 不会"输出暗示世纪的信息"，它就是个两位年份输出。我见过有人在报表里写TO_CHAR(d,'RR')期望得到1998这样的四位数，结果拿到98，然后怀疑人生。想要四位数就写RRRR或YYYY，这两个在TO_CHAR下都是四位输出。

RRRR和YYYY的区别体现在解析方向：TO_DATE('98','RRRR')和TO_DATE('98','YYYY')都能解析出四位年份，行为上和 RR 很接近。日常写代码，解析用YYYY（配四位输入）或者RR（配两位输入），格式化输出用YYYY或YYYY-MM-DD，RRRR少用，容易让后来维护的人以为里面有啥讲究。

3.3 闰年陷阱：RR 推断出的世纪会直接决定日期合法性

这个坑是我在某次批量导入里踩出来的。当时导的是员工入职日期，字段YYMMDD，脚本用了RR。导入跑到一半报ORA-01839: date not valid for month specified，日志里只看到行号，没看到具体值，排查花了小半天。

原因很直接：29-02-99这个字符串，RR 把99推成 1999 年，而 1999 年不是闰年，2 月 29 日不存在，于是报错。但如果你手贱把它改成YY，99会被推成 2099 年——2099 也不是闰年，同样报错。真正有区别的是一批数据里的混合情况：

有意思的地方在于：如果这批数据是YY格式，29-02-99会被推到 2099，2099 不是 4 的倍数，同样不是闰年，一样报错。但29-02-04呢？RR 给 2004（闰年，成功），YY 给 2104（2104 是 4 的倍数，能被 100 整除吗？不能，所以也是闰年，也成功）。真正会分道扬镳的是29-02-96这种：RR → 1996（闰年，成功），YY → 2096（闰年，也成功）。嗯，闰年判定只看能否被 4 整除（世纪年再判 400），两位年份推出来的世纪只要落在同一类里，结果就一致。

那什么情况下 RR 和 YY 在闰年上会打架？需要推断出的年份一个闰一个不闰。比如29-02-00：RR → 2000（能被 400 整除，闰年），YY → 2100（能被 100 整除但不能被 400 整除，不是闰年，报错）。这就是差异点。所以同一句TO_DATE('29-02-00','YY-MM-DD')会比TO_DATE('29-02-00','RR-MM-DD')更容易报错。

实操建议：批量导入前，先用一条查询把候选数据里所有MMDD = '0229'的行捞出来单独核对，比跑到一半报错再回滚强得多。

-- 导入前预检：把所有 2 月 29 日的记录单独列出来 SELECT id, date_str FROM staging_import WHERE SUBSTR(date_str, 3, 4) = '0229';

4. 跨语言对比：三套完全不同的两位年份规则

这一节是我觉得最值得写、但网上最少人讲的部分。同一个45，在不同环境里解析出来的年份可能差一百年，而且没有谁对谁错，纯属各家设计取舍不同。做跨系统数据交换的时候，这就是明晃晃的坑。

4.1 三套规则的对照

看48：Oracle 给 2048，Java 老 API 给 1948——差一百年。看67：Oracle 给 1967，Python 给 2067——又差一百年。而 Java 新老两套 API 自己内部就不一致，同一个语言两种行为，这个最容易阴人。

具体解释一下：

• JavaSimpleDateFormat的窗口是"当前时间往前 80 年、往后 20 年"，2024 年时窗口是 1944 到 2044。两位年份会被映射到落在这个窗口里的那个世纪。所以48→ 2048 超出窗口上限，取 1948。
• JavaDateTimeFormatter（也就是java.time那套）用的是"reduced value"基准 2000，yy解析出来就是20xx，99→ 2099，00→ 2000。跟 Oracle 的 YY 一个路数。
• Python / C 标准库走 POSIX 的老约定：69到99归 19xx，00到68归 20xx。分界线在 68/69，不是 50。

这三套规则摆在一起，意味着什么？意味着你从 A 系统导出的 CSV，字段是YY-MM-DD，导入到 B 系统，如果两边解析器不同，中间一段数据会静默错位一百年，不报错、不告警。这种错最难查，因为数据看起来"有值"，只是年份不对。

4.2 数据迁移里的实战教训

我在一个跨系统对账项目里遇到过一模一样的场景。源端导出的日期是两位年份，目标端导入脚本用 Oracle 的RR解析。两边数据量三百万行左右，对账时发现 1960 年代出生的用户，生日全部变成了 2060 年代，而 1950 年代的反而正常。

排查过程：抽了一万行样本，把源端的原始字符串和目标端入库后的日期并排列出来，一眼就看出问题集中在50到68这个区间。源端用的是 Python 生成的 CSV，%y解析时把60归到了 2060；目标端RR把60归到了 1960。中间差了一百年。

修复方案的思路是：不要在解析环节修，要在源头修。让源端导出时把年份扩成四位，或者导出时附带一份"基准年"的元数据，导入脚本根据基准年做一次显式换算。硬改目标端解析规则是最差的做法——因为你永远不知道还有没有第三个系统在消费同一份文件。

如果实在改不了源端，那就用一条校验 SQL 先过一遍：

-- 导入前校验：找出 RR 解析结果落在"未来 20 年外"的记录 -- 这类数据大概率是世纪归属有问题，需要人工复核 SELECT id, raw_date_str, TO_CHAR(TO_DATE(raw_date_str, 'RR-MM-DD'), 'YYYY-MM-DD') AS parsed FROM staging_import WHERE TO_DATE(raw_date_str, 'RR-MM-DD') > ADD_MONTHS(SYSDATE, 240);

如果业务上根本不存在未来日期（比如入职日期、出生日期、合同签署日期），这条查询能把绝大部分错位数据捞出来。实测很有效。

5. 生产环境排查：怎么找出 RR 埋下的雷

这一节讲具体动作。不是理论，是打开终端就能敲的命令。

5.1 先摸清环境的 NLS 底数

数据库级和会话级的NLS_DATE_FORMAT可能不一致，先都看一眼：

-- 数据库默认设置 SELECT parameter, value FROM nls_database_parameters WHERE parameter IN ('NLS_DATE_FORMAT', 'NLS_DATE_LANGUAGE'); -- 当前会话生效的设置 SELECT parameter, value FROM nls_session_parameters WHERE parameter IN ('NLS_DATE_FORMAT', 'NLS_DATE_LANGUAGE');

如果数据库级是DD-MON-RR，会话级也是DD-MON-RR，那说明整个库的所有隐式转换都在走 RR。这时候你要特别小心两类代码：一是WHERE date_col = '字符串'这种隐式转换，二是INSERT INTO ... VALUES ('15-3月-24')这种不给格式串的写法。

我见过一个更隐蔽的变体：某个连接池在建立连接时执行了ALTER SESSION SET NLS_DATE_FORMAT='YYYY-MM-DD'，而另一套批处理任务连的是同一个库但用了不同连接池，没执行这句。结果同样的 SQL，在 Web 端跑正常，在批处理里跑就报ORA-01861: 文字与格式字符串不匹配。查了两天才发现是会话配置不同。

5.2 用脚本把代码里的两位年份格式串扫出来

代码库里搜一遍，比人工翻代码快得多。SQL 文件、Java 源码、存储过程导出文件都要扫：

# 扫 SQL 和 Java 源码里带 RR 或 YY 的格式串 grep -rniE "(to_date|to_char)[[:space:]]*\([^)]*['\"][^'\"]*(rr|yy)[^'\"]*['\"]" \ --include="*.sql" --include="*.java" --include="*.xml" --include="*.prc" .

扫出来的结果会很多，需要分三档处理：

• TO_CHAR(x,'RR')或TO_CHAR(x,'YY')：只影响显示，优先级低，但要确认下游有没有消费这个两位输出。
• TO_DATE(str,'RR...')：真正的解析入口，逐条核对输入数据的实际位数和取值范围。
• TO_DATE(str,'YY...')：高危，优先按 RR 或者带四位的方案重写。

数据库内部的存储过程也得扫：

SELECT owner, name, type FROM dba_source WHERE UPPER(text) LIKE '%TO_DATE%' AND (UPPER(text) LIKE '%''RR%' OR UPPER(text) LIKE '%''YY%') ORDER BY owner, name;

5.3 检查有没有用 VARCHAR2 存日期

这是万恶之源。日期存在字符串列里，等于把解析规则永久固化到了数据里，换个环境、换个客户端就变样。

-- 找出名字可疑、类型是字符串的列 SELECT owner, table_name, column_name, data_type, data_length FROM dba_tab_columns WHERE data_type IN ('VARCHAR2', 'CHAR') AND data_length <= 20 AND ( UPPER(column_name) LIKE '%DATE%' OR UPPER(column_name) LIKE '%TIME%' OR UPPER(column_name) LIKE '%DT%' OR UPPER(column_name) LIKE '%DAY%') ORDER BY owner, table_name;

名单出来之后，逐个抽样看格式。抽样 SQL 很简单，SELECT column_name FROM table WHERE ROWNUM <= 20，肉眼扫一眼就知道是YYYY-MM-DD、YYMMDD还是别的什么野路子。这一步省不得，因为迁移方案完全取决于实际格式。

5.4 隐式转换：出事概率最高的一类写法

排序一下危险程度：

第三、四种写法应该成为团队规范。第一种写法在某些代码评审里应该直接打回。我待过的一个团队就把WHERE 日期列 = '...'写进了静态检查规则，扫描到就报错，效果很好——一开始大家抱怨，三个月