相同的时区，但current_timestamp不同于systimestamp

Question

这是一个反复出现的话题，但我仍然找不到解决办法。据我了解，SYSTIMESTAMP将根据服务器时区返回时间，而CURRENT_TIMESTAMP将根据客户端时区返回时间。

我正在从我家连接到一个远程Oracle数据库。如果我跑：

SELECT
  DBTIMEZONE, SESSIONTIMEZONE
FROM
  dual;

我得到：

DBTIMEZONE        SESSIONTIMEZONE                                                            
----------------- -----------------
America/Sao_Paulo America/Sao_Paulo   

但如果我尝试：

select systimestamp, current_timestamp from dual;

我得到：

SYSTIMESTAMP                       CURRENT_TIMESTAMP                            
---------------------------------- ---------------------------------------------
26/01/21 15:52:46,259759000 -03:00 26/01/21 16:52:46,259770000 AMERICA/SAO_PAULO

我在服务器端双重检查了tzdata信息，不知道我错过了什么。有人能帮忙吗？

Answer 1

如果Oracle文档能够更清楚地处理这些问题，那就更好了，不是吗？

sys.... (如sysdate和systimestamp)是运行数据库软件(“服务器”)的操作系统的日期-时间/时间戳。没有Oracle函数来检索操作系统时区；但是，可以在调用systimestamp时查看报告的内容。

另一方面，dbtimezone是一个几乎任意的时区，在创建db时设置；通常它被设置为UTC (GMT)。除了数据类型的值()以外，它不用于任何内容()--这些值被转换为“数据库”时区，并作为时间戳存储在磁盘上，而该时区中没有时区组件。

dbtimezone只需要与自身保持一致--它与服务器上操作系统的时区完全无关。您可以随意更改DB时区-，但当数据库中有类型为timestamp with LOCAL time zone的表且并非所有这些列都为空时，除外。

这意味着dbtimezone是非常没有意义的；它并不真正控制，任何。它与systimestamp无关，也没有简单地向您显示服务器操作系统时区的功能。

回到我在上面说的话..。如果文件.对吗？

您可能需要检查服务器上的当前时间戳(如果您可以访问它)和/或它的时区。例如，您可能会发现，它被设置为来自UTC的固定偏移量，因此它可能不反映夏令时。或者别的什么。但是，与current_timestamp和sessiontimezone相比，这才是正确的“事情”。您如何在服务器上这样做(即使您可以访问它)将取决于操作系统- Windows、Linux、Unix等。无论如何，您的systimestamp显示‘-03:00’，就好像它是来自UTC的固定偏移量一样。

编辑-深入研究，如果我理解正确的话，巴西选择了一个例外(？？)不遵守今年夏令时的规定。所以，似乎-03:00偏移量是正确的。根据您报告的值，Oracle似乎不知道这一点，并将“America/圣保罗”视为受DST影响。这就是为什么systimestamp是正确的，而current_timestamp是关闭一个小时。

要么Oracle不“知道”这一点，要么它发布了一个尚未应用于您的系统的修补程序。或者别的什么。显然，服务器上的操作系统知道这一点。问题在数据库中，它不是关于"db“或”会话“时区(因为它们是相同的)，而是时区本身，以及它在这个特殊年份意味着什么。

至于它的价值，我只是在我的系统上测试-如果我select systimestamp at time zone '-03:00'我得到正确的当前时间在圣保罗(在线检查)；如果我更改时区为'America/Sao_Paulo'，我得到一个小时后。这是意料之中的-我的系统没有补丁(我不是付费客户，我只是玩一个“实践”版本的数据库，这不符合我的补丁)。