PL/SQL日期显示乱码或格式不一致的根本原因是NLS参数未对齐；DATE类型本身无格式，仅存二进制时间戳，显示格式由会话级NLS_DATE_FORMAT等参数控制，设置不匹配会导致查询异常、转换报错及WHERE条件失效。
PL/SQL里日期显示乱码或格式不一致，根本原因是NLS参数没对齐
Oracle中DATE类型本身不存格式，只存二进制时间戳；你看到的“27-JUL-26”或“2026-07-27 14:15:00”全是会话级NLS参数控制的展示结果。一旦NLS_DATE_FORMAT、NLS_LANG、客户端工具（如PL/SQL Developer）设置不匹配，就会出现：查询结果看着像字符串、TO_DATE报错、WHERE条件查不到数据。
- 检查当前会话格式：
SELECT * FROM nls_session_parameters WHERE parameter IN ('NLS_DATE_FORMAT', 'NLS_TIMESTAMP_FORMAT'); - 临时修改（仅当前会话）：
ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS'; - 永久生效需设环境变量（Windows）：
NLS_DATE_FORMAT=YYYY-MM-DD HH24:MI:SS，重启PL/SQL Developer才生效 -
NLS_LANG必须与数据库字符集兼容，中文环境常见值是SIMPLIFIED CHINESE_CHINA.ZHS16GBK，否则TO_CHAR(..., '月')可能显示为问号
用TO_CHAR和TO_DATE时，大小写、拼写、空格一个都不能错
TO_CHAR和TO_DATE不是万能转换器，它们严格按格式模型解析——错一个字母、多一个空格、大小写混用，都会报ORA-01821: date format not supported或ORA-01830: date format picture ends before converting entire input string。
- 小时必须用
HH24（24小时制）或HH12（12小时制），写成hh24或Hh24都行（不区分大小写），但HH默认是12小时制，容易漏AM/PM - 分钟只能用
MI，MM是月份——TO_DATE('2026-07-27 14:30', 'YYYY-MM-DD HH24:MM:SS')会把30当成7月，直接报错 - 带中文的格式必须用双引号包裹非格式字符：
TO_CHAR(SYSDATE, 'YYYY"年"MM"月"DD"日" HH24:MI:SS')，单引号或不加引号会失败 - 字符串转日期时，输入长度不能超过格式长度：
TO_DATE('2026-07-27', 'YYYY-MM-DD HH24:MI:SS')可以（自动补00:00:00），但TO_DATE('2026-07-27 14:30:45.123', 'YYYY-MM-DD HH24:MI:SS')会截断毫秒并丢弃，不报错但精度丢失
WHERE条件里别直接拼字符串，小心BETWEEN和隐式转换陷阱
写WHERE create_time BETWEEN '2026-07-01' AND '2026-07-31'看着简洁，实际依赖NLS设置，且BETWEEN包含边界时间的00:00:00——这意味着'2026-07-31'只匹配到当天0点，31号全天数据全丢。
- 安全写法是显式转日期：
WHERE create_time >= TO_DATE('2026-07-01', 'YYYY-MM-DD') AND create_time - 如果字段是
TIMESTAMP，用TO_TIMESTAMP，别用TO_DATE——后者会丢掉毫秒，且无法处理时区 - 避免依赖隐式转换：
WHERE create_time = '2026-07-27'在不同NLS下可能被解释成27-JUL-26或2026-07-27 00:00:00，行为不可控 - 查“某一天所有数据”，别用
=，用范围：create_time >= DATE'2026-07-27' AND create_time ，<code>DATE'...'语法最简且无NLS依赖
DATE和TIMESTAMP选哪个？看业务是否需要秒级精度或时区
DATE类型只精确到秒，不带时区；TIMESTAMP可到纳秒（TIMESTAMP(9)），还能存时区信息（TIMESTAMP WITH TIME ZONE）。选错类型会导致数据截断或比较出错。
- 普通业务系统（如订单创建时间、审批时间），
DATE足够，存储开销小，索引效率略高 - 金融、日志、IoT等需毫秒对齐的场景，必须用
TIMESTAMP，否则SYSDATE和CURRENT_TIMESTAMP返回值精度不同，插入后查不出来 -
TIMESTAMP WITH LOCAL TIME ZONE会自动转成本地时区存储，跨时区应用慎用——用户在北京和纽约同时操作，存的可能是同一物理时刻的不同字符串表示 - 函数行为有差异：
ADD_MONTHS支持DATE和TIMESTAMP，但EXTRACT只能用于TIMESTAMP，TRUNC对TIMESTAMP默认截到秒，要截到天得写TRUNC(ts, 'DD')
真正麻烦的从来不是语法本身，而是NLS参数散落在操作系统环境变量、数据库初始化参数、会话级设置、客户端工具配置四个地方，改一处漏三处。动手前先跑一遍SELECT * FROM nls_session_parameters，确认你看到的“格式”到底是哪一层定的。
