Oracle数据库中处理日期和时间的数据类型主要有DATE、TIMESTAMP以及带时区变体TIMESTAMP WITH TIME ZONE和TIMESTAMP WITH LOCAL TIME ZONE。虽然它们都用于保存时间点，但在内部存储精度、时区敏感性和运算行为上存在显著差异，选错类型轻则丢失毫秒精度，重则导致跨时区数据不一致。理解这些差异是设计健壮数据模型的前提。
精度与存储机制的根本区别
DATE类型是Oracle最经典的日期类型，它固定使用7个字节存储，分别记录世纪、年、月、日、时、分、秒。由于没有小数秒字段，DATE的最小时间粒度就是1秒。例如执行TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS')时，秒之后不会出现任何数字。在很多业务场景中，订单创建时间、生日、合同生效日期等只需要到秒就足够了，DATE完全能胜任。
而TIMESTAMP类型专门为了解决亚秒精度而引入。它的存储空间为11字节，前7字节与DATE完全相同，额外的4字节用于存放小数秒，默认保留6位，也就是微秒级别。如果业务需要更高的时间分辨率，可以在定义列时指定精度，例如TIMESTAMP(9)可以保存9位小数秒，达到纳秒级别。不过精度越高，存储开销和索引体积也会相应增加，实际项目中很少超过6位。
下面的建表语句展示了DATE和TIMESTAMP在列定义上的区别，以及插入数据后查询得到的结果格式。注意TIMESTAMP默认会显示小数秒，而DATE不会。
CREATE TABLE date_demo (
id NUMBER,
dt DATE,
ts TIMESTAMP
);
INSERT INTO date_demo VALUES (1, SYSDATE, SYSTIMESTAMP);
SELECT id,
TO_CHAR(dt, 'YYYY-MM-DD HH24:MI:SS') AS date_value,
TO_CHAR(ts, 'YYYY-MM-DD HH24:MI:SS.FF6') AS timestamp_value
FROM date_demo;
从上面的结果可以看出，DATE列通过TO_CHAR即使指定FF格式也不会出现小数秒，而TIMESTAMP列则可以格式化出微秒部分。这是两者最直观的差异，也是选择类型时首先要考虑的因素。
时区语义与带时区变体
原生的DATE和TIMESTAMP都不保存时区信息，它们只表示一个不带任何时区上下文的本地时间。数据库会话的时区设置会影响某些函数的返回结果，但一旦数据写入表，后续修改会话时区并不会改变已存储的值。例如用户在上海写入时间2025-01-01 10:00:00，另一个用户在纽约查询看到仍然是2025-01-01 10:00:00，不会自动转换成纽约当地时间。
如果系统需要跨时区协作，应该使用TIMESTAMP WITH TIME ZONE或TIMESTAMP WITH LOCAL TIME ZONE。前者存储时区偏移量或时区名称，能够保留原始时区信息；后者则将时间归一化到数据库时区存储，查询时根据会话时区自动转换显示。两者都基于TIMESTAMP扩展，同样支持小数秒精度。示例中可以看到时区值如何被保留和转换。
CREATE TABLE tz_demo (
id NUMBER,
tstz TIMESTAMP WITH TIME ZONE,
tsltz TIMESTAMP WITH LOCAL TIME ZONE
);
ALTER SESSION SET TIME_ZONE = 'Asia/Shanghai';
INSERT INTO tz_demo VALUES (
1,
TIMESTAMP '2025-01-01 10:00:00 Asia/Shanghai',
TIMESTAMP '2025-01-01 10:00:00 Asia/Shanghai'
);
ALTER SESSION SET TIME_ZONE = 'America/New_York';
SELECT id, tstz, tsltz FROM tz_demo;
同一行数据在不同会话时区下，TIMESTAMP WITH TIME ZONE显示的原始时区不变，而TIMESTAMP WITH LOCAL TIME ZONE会自动换算为当前会话时区对应的时间。这种差异在多租户应用和全球化系统中非常关键。
另外需要注意的是，SYSDATE返回的是数据库服务器的操作系统时间，类型为DATE；SYSTIMESTAMP返回数据库服务器时间，类型为TIMESTAMP WITH TIME ZONE。CURRENT_DATE和CURRENT_TIMESTAMP则受会话时区影响，使用时务必分清。
日期运算与函数行为对比
DATE类型支持直接与数字进行加减运算，数字代表天数。例如SYSDATE + 1表示明天，SYSDATE - 1/24表示一小时前。这种运算返回DATE类型。而TIMESTAMP与数字运算时，Oracle会先把TIMESTAMP隐式转换为DATE，因此结果也是DATE，小数秒部分会丢失。如果需要保留小数秒，必须使用INTERVAL进行加减。
下面的示例对比了DATE和TIMESTAMP在加减操作上的行为差异。第一段使用数字运算，第二段使用INTERVAL DAY TO SECOND保留亚秒精度。
-- DATE运算，返回DATE
SELECT SYSDATE AS now_date,
SYSDATE + 1/24 AS one_hour_later
FROM dual;
-- TIMESTAMP与数字运算，返回DATE，丢失小数秒
SELECT SYSTIMESTAMP AS now_ts,
SYSTIMESTAMP + 1/24 AS one_hour_later_from_ts
FROM dual;
-- TIMESTAMP与INTERVAL运算，返回TIMESTAMP，保留小数秒
SELECT SYSTIMESTAMP AS now_ts,
SYSTIMESTAMP + INTERVAL '1' HOUR AS one_hour_later_with_interval
FROM dual;
从结果可以观察到，第二种方式得到的值不包含小数秒，类型已经变为DATE。如果程序期望拿到TIMESTAMP却收到了DATE，在后续绑定变量或序列化时可能出现精度异常。因此涉及高精度时间戳的运算，建议统一使用INTERVAL。
在函数层面，EXTRACT函数可以从DATE和TIMESTAMP中提取年、月、日、时、分、秒以及时区信息；TO_TIMESTAMP和TO_TIMESTAMP_TZ用于字符串到时间戳的转换；TO_CHAR则支持FF格式模型显示小数秒。需要特别注意的是，TO_DATE函数不能解析小数秒，即使格式串中包含FF也会报错，这是很多开发者在迁移数据时遇到的坑。
如何选择合适的日期时间类型
在数据库设计阶段，日期时间类型的选择应当基于业务对精度、时区和存储成本的实际需求。如果只是记录业务发生日期、单据生效日期、员工入职日期等，使用DATE即可，7字节的固定存储更节省空间，运算和索引效率也更高。很多遗留系统的日期列默认都是DATE，没有必要盲目升级为TIMESTAMP。
当业务需要记录事件发生的精确时刻，例如日志埋点、消息队列消费时间、金融交易时间戳、物联网传感器上报时间等，应当选择TIMESTAMP。默认6位微秒精度可以满足绝大多数应用，只有在极少数需要纳秒分辨率的科学计算或高频交易场景才使用TIMESTAMP(9)。
如果应用的用户分布在多个时区，或者需要保存用户原始时区以备审计，则使用TIMESTAMP WITH TIME ZONE。如果是SaaS系统，所有用户数据统一存储但展示时按各自时区转换，使用TIMESTAMP WITH LOCAL TIME ZONE能减少转换逻辑。不过需要注意，TIMESTAMP WITH TIME ZONE在索引和分布式查询中可能带来额外的性能开销，因为时区转换需要计算。
最后列出三种常用类型的存储空间对比：DATE固定7字节，TIMESTAMP默认11字节，TIMESTAMP WITH TIME ZONE最小13字节（取决于时区信息长度）。在大数据量场景下，每行多出几字节累积的存储和缓存成本不可忽视。因此在满足业务需求的前提下，选择最简单的类型往往是明智的。
Oracle DATETIMESTAMP日期时间类型修改时间：2026-08-25 20:53:34