应用连接Oracle 19c时SYSDATE与CURRENT_DATE时间偏移问题

该时间偏移的核心原因是Oracle 19c实例启动时加载的时区配置错误，与操作系统实际时区、当地夏令时规则不匹配，结合Oracle时间函数的取值逻辑可以完全复现你看到的现象：

• SYSDATE、SYSTIMESTAMP的返回值完全取数据库服务器上Oracle进程运行时绑定的时区，和你SSH登录服务器执行date看到的Shell会话时区、客户端会话时区均无关。你查询到SYSTIMESTAMP返回+02:00偏移，说明Oracle实例自身把数据库侧时区识别成了GMT+2（对应中欧夏令时规则），而加那利群岛夏季正确偏移为GMT+1，刚好存在1小时偏差。
• SESSIONTIMEZONE、CURRENT_DATE、CURRENT_TIMESTAMP、LOCALTIMESTAMP取值依赖客户端会话的时区配置，你从apx1发起连接时客户端侧时区识别正确（+01:00），因此这几个函数的返回值符合本地时间预期，和数据库侧配置错误无关。
• 出现“服务器执行date时间正确，但Oracle时间错误”的典型原因是：Oracle进程启动时会读取当时进程环境变量里的TZ参数，如果安装时未将正确时区配置到oracle用户的全局环境变量、或启动脚本中硬编码了错误的TZ值（比如配成了Europe/Madrid这类中欧时区，夏季偏移为+02:00），后续即使你修改了操作系统时区、登录Shell看到的时间正确，已经启动的Oracle进程仍会沿用启动时加载的错误时区配置。
• 额外注意：不要用BST这类缩写配置时区，该缩写同时对应多个不同偏移的时区，Oracle解析时很容易匹配到错误的夏令时规则，必须使用标准IANA时区名配置。

按以下顺序确认问题点：

1. 登录数据库执行以下语句，确认数据库侧时间偏移：

SELECT dbtimezone, systimestamp FROM dual;

异常场景下systimestamp会显示+02:00偏移。
2. 登录bdx1服务器，找到Oracle实例的pmon进程ID，查询Oracle进程实际加载的TZ变量：

# 替换ORCL为你的实际实例名
ps -ef | grep pmon | grep ORCL
# 替换上方命令输出的PID为实际值
cat /proc/<PID>/environ | tr '\0' '\n' | grep TZ

异常场景下该命令返回的TZ值不会是加那利群岛对应的标准IANA时区Atlantic/Canary，通常是Europe/Madrid、CET这类对应中欧时区的值。

临时恢复（无需重启库，重启后失效） #

如果业务暂时不允许停库，所有需要取本地时间的场景，暂时用CURRENT_DATE（DATE类型）、LOCALTIMESTAMP（TIMESTAMP类型）替代SYSDATE、SYSTIMESTAMP即可。当前你环境的会话时区配置正确，这两个函数的返回值符合加那利本地时间要求。

永久修复（需重启数据库，彻底解决） #

1. 用root用户登录bdx1，将操作系统全局时区设置为加那利群岛对应的标准IANA时区：

timedatectl set-timezone Atlantic/Canary
# 验证配置
timedatectl

确认输出中Time zone为Atlantic/Canary，当前时间偏移为+01:00，夏令时状态为active。
2. 切换到oracle用户，编辑oracle用户的环境变量配置文件（根据使用的Shell选择~/.bash_profile、~/.profile），追加正确的时区配置：

export TZ=Atlantic/Canary

保存后执行source 对应配置文件让配置生效，同时检查Oracle启动脚本、systemd服务配置文件、/etc/oratab中是否存在硬编码的错误TZ配置，全部修正为上述值或直接删除冗余配置。
3. 重启数据库实例让Oracle进程重新加载正确的时区配置：

lsnrctl stop
sqlplus / as sysdba
shutdown immediate
startup
lsnrctl start

4. 重启后执行验证语句，确认结果符合预期：

SELECT 
  to_char(sysdate, 'dd mm yyyy hh24:mi:ss') "SYSDATE",
  to_char(current_date, 'dd mm yyyy hh24:mi:ss') "CURRENT_DATE",
  systimestamp
FROM dual;

正常场景下SYSDATE与CURRENT_DATE值完全一致，systimestamp显示偏移为+01:00，和操作系统date命令返回的时间差在秒级以内。

注意：不要直接执行ALTER DATABASE SET TIME_ZONE修改数据库时区参数，该参数仅影响TIMESTAMP WITH LOCAL TIME ZONE类型的列存储逻辑，不会改变SYSDATE/SYSTIMESTAMP的返回值，无法解决该偏移问题。

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