Oracle TIMESTAMP类型是否会根据本地时区调整存储的日期时间？

首先明确结论：Oracle原生的TIMESTAMP类型本身不携带时区信息，也不会主动做时区调整。你观察到的"存储的是本地时间"，实际是两个环节的转换导致的：

• JDBC驱动写入环节：java.util.Date本身存储的是UTC时间戳，但JDBC驱动默认会使用JVM的默认时区，将该时间戳转换为对应时区的年月日时分秒数值，再写入无时区的TIMESTAMP字段，相当于写入的已经是本地时区换算后的时间值。
• 客户端显示环节：SQL Developer默认会使用操作系统本地时区格式化展示存储的时间数值，即使你存的是UTC时间，也会被转换成你本地时区的时间显示，容易造成误解。

如果要验证真实存储的数值，可以执行SQL查询：SELECT TO_CHAR(END_TIME, 'YYYY-MM-DD HH24:MI:SS') FROM JobExecution，输出的就是字段实际存储的时分秒数值，没有经过时区转换。
额外补充：如果使用TIMESTAMP WITH TIME ZONE（简称TIMESTAMPTZ）类型，Oracle会存储原始的时区信息，查询时可以根据需求转换到不同时区展示。

推荐优先选择直接存储UTC时间的方案，该方案从根源避免跨时区部署、业务跨时区查询的逻辑混乱，后续维护成本远低于读取时转换的方案。具体实现可以根据你的业务约束二选一：

方案1：修改字段类型为TIMESTAMP WITH TIME ZONE（推荐度最高） #

• 替换Java侧的时间类型：弃用老旧的java.util.Date，改用java.time.Instant，该类型本身就是UTC时间戳，不存在时区转换歧义。
• Spring JDBC 3.x以上版本原生支持Instant到TIMESTAMP WITH TIME ZONE的映射，不需要额外配置，写入时直接传递Instant.now()即可，读取时也直接返回Instant，全程不会出现时区转换错误。

方案2：保留TIMESTAMP字段类型，强制全局使用UTC时区 #

如果无法修改表结构，可以通过以下方式保证存储的是UTC时间：

• 给JVM添加启动参数：-Duser.timezone=UTC，强制JVM默认时区为UTC，JDBC驱动读写时间时都会使用UTC做转换，写入TIMESTAMP的就是UTC对应的时分秒数值。
• 如果不能修改JVM全局配置，可以在时间写入/读取的逻辑中手动指定UTC时区，使用java.time包的ZonedDateTime手动转换为UTC时间后再做读写。

辅助验证配置 #

可以将SQL Developer的默认时区修改为UTC，避免显示误导：打开SQL Developer的 工具 -> 首选项 -> 数据库 -> NLS，将时区配置改为UTC，之后查询展示的就是字段的原始UTC时间值。

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