Oracle 10g时区混乱

前端之家收集整理的这篇文章主要介绍了Oracle 10g时区混乱前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
SELECT TO_CHAR(SYSDATE,'YYYY-MM-DD HH24:MI'),TO_CHAR(CURRENT_DATE,TO_CHAR(SYSTIMESTAMP,'YYYY-MM-DD HH24:MI TZR'),TO_CHAR(CURRENT_TIMESTAMP,TO_CHAR(LOCALTIMESTAMP,DBTIMEZONE,SESSIONTIMEZONE
  FROM DUAL;

回来了:

2012-01-16 11:42
2012-01-16 11:42    
2012-01-16 11:42 -06:00 
2012-01-16 11:42 -06:00 
2012-01-16 11:42 +00:00 
+00:00  
-06:00

它似乎认为数据库时区是GMT,但SYSDATE与CURRENT_DATE相同.

当我远程进入该服务器(Windows)时,时区显然是CST(但是,我知道这可能是我的终端服务客户端时区偏移,但是这台机器上没有终端服务,只是管理)

对阿姆斯特丹的服务器运行相同的事情(4分钟后,所有来自同一个TOAD客户端),我得到:

2012-01-16 18:46
2012-01-16 11:46    
2012-01-16 18:46 +01:00 
2012-01-16 11:46 -06:00 
2012-01-16 11:46 +00:00 
+02:00  
-06:00

注意2,但至少SYSDATE和CURRENT_DATE是不同的.

这里发生了什么? SYSDATE来自哪里,还有其他影响它的东西吗?

似乎DBTIMEZONE没有用于任何这些东西?那么DBTIMEZONE用于什么?

这里实际上有3个时区,而不是2个

>会话/客户端的时区

>显示在SESSIONTIMEZONE
>这是CURRENT_DATE,LOCALTIMESTAMP和CURRENT_TIMESTAMP的时区.这三者之间的区别是返回类型,它们分别返回DATE,TIMESTAMP和TIMESTAMP WITH TIME ZONE)

>数据库时区

>显示在DBTIMEZONE中
>这是用于TIMESTAMP WITH LOCAL TIME ZONE值的内部存储的时区.请注意,值在插入/选择时转换为/从会话时区转换,因此它实际上并不像看起来那么重要
>这不是SYSDATE / SYSTIMESTAMP的时区

>数据库操作系统时区

>在unix中,它基于Oracle启动时的TZ变量
>这是SYSDATE和SYSTIMESTAMP的时区

在您的第一个示例中,我可以看到会话TZ是UTC-6,数据库TZ是UTC,数据库OS时区是UTC-6.

在第二个示例中,数据库TZ是UTC 2,数据库OS时区是UTC 1.

猜你在找的Oracle相关文章