Oracle PL/SQL中DATE类型始终存储精确到秒的时间点，显示必须用TO_CHAR显式格式化，不可依赖NLS_DATE_FORMAT；TO_DATE解析需严格匹配格式模型，避免隐式转换；日期比较和查询务必显式转换，防止因时间部分或环境差异导致逻辑错误。
Oracle PL/SQL 中处理时间日期，核心不是“选哪个类型”，而是“别把 DATE 当字符串用，也别指望它自动按你想要的格式显示”。DATE 类型永远存的是精确到秒的时间点（YYYY-MM-DD HH24:MI:SS），但默认怎么展示、怎么解析，完全由会话参数和函数控制。
to_char() 是唯一可控的格式输出方式
直接 SELECT sysdate FROM dual 看到的格式，取决于 NLS_DATE_FORMAT，不可靠，也不可跨环境复现。真正能稳定输出指定格式的，只有 TO_CHAR。
- 必须显式传入格式模型，比如
'yyyy-mm-dd hh24:mi:ss'；漏掉hh24只写hh，就变成 12 小时制，可能出错 -
mi表示分钟，mm表示月份——写成'yyyy-mm-dd hh24:mm:ss'不报错但结果错（把分钟位置显示成月份） - 要显示中文，必须用双引号包裹字面量：
'yyyy"年"mm"月"dd"日" hh24:mi:ss'，否则年被当成格式符解析失败 -
fm前缀可去掉前导空格，比如'fmmonth dd, yyyy'输出september 17, 2026，而非september 17, 2026
to_date() 解析字符串时，格式必须严格匹配
TO_DATE('2026-09-17', 'yyyy-mm-dd') 没问题，但 TO_DATE('17/09/2026', 'yyyy-mm-dd') 会报 ORA-01843: not a valid month —— 因为字符串里的 17 被当成了年份，09 当成月份，2026 就超长了。
- 源字符串和格式模型长度不必一致，但顺序和含义必须对齐：日期部分对应
dd，月份对应mm，年份对应yyyy或yy - 两位年份（
yy）有滑动窗口风险，TO_DATE('01-DEC-25', 'dd-mon-yy')在默认 NLS 设置下可能被解释为 2025 年，也可能被解释为 1925 年 - 月份缩写（
mon）依赖NLS_DATE_LANGUAGE，英文环境用'dec'，中文环境得用'12月'，混用必报错
DATE 类型本身不带时区，别拿它存 UTC+8 或北京时间
DATE 只存一个本地时间值，不记录时区信息。插入 SYSDATE 得到的是数据库服务器所在时区的时间戳，查询时也不会自动转换。
- 如果业务需要区分 UTC 和本地时间，必须用
TIMESTAMP WITH TIME ZONE，并配合FROM_TZ、AT TIME ZONE等函数 - 用
DATE存“2026-09-17 10:00:00”再传给前端，前端按自己时区渲染，结果可能错 8 小时——这不是 Oracle 的问题，是设计选型问题 -
INTERVAL类型适合做时间差计算（如sysdate + INTERVAL '7' DAY），但不能和DATE直接拼接字符串，必须用算术或函数
alter session set nls_date_format 只影响默认显示，不改变数据本质
执行 ALTER SESSION SET NLS_DATE_FORMAT = 'yyyy-mm-dd hh24:mi:ss' 后，SELECT sysdate FROM dual 看起来“正常”了，但这只是会话级显示覆盖，对存储、索引、比较逻辑毫无影响。
- 该设置不会让
WHERE regtime > '2026-09-01'这种隐式转换变安全——它依然依赖 NLS 设置，且极易因环境不同而失败 - 生产代码中禁止依赖
NLS_DATE_FORMAT做条件过滤，必须显式用TO_DATE或绑定变量 - 修改注册表或环境变量让
NLS_DATE_FORMAT全局生效，只适用于 DBA 统一管控场景，开发不应假设这个值存在
最常被忽略的一点：DATE 字段里存了 2026-09-17 00:00:00，在 PL/SQL 工具里默认只显示 2026-09-17，但这不代表它没时间部分——用 TO_CHAR(col, 'hh24:mi:ss') 一查，全是 00:00:00。这种“看不见”的时间部分，会在范围查询（比如 BETWEEN）里悄悄导致数据遗漏。
