相同时区，但 current_timestamp 不同于 systimestamp
Same timezone but current_timestamp differs from systimestamp
这是一个反复出现的话题，但我仍然找不到解决方案。据我了解，SYSTIMESTAMP 将 return 基于服务器时区的时间，而 CURRENT_TIMESTAMP 将 return 基于客户端时区。
我正在从家里连接到远程 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 信息，但无法弄清楚我遗漏了什么。有人可以帮忙吗？
如果 Oracle 文档能更清楚地说明这些事情，那就更好了，不是吗？
sys....（如sysdate和systimestamp）是操作系统运行的date-time/timestamp数据库软件（“服务器”）。没有 Oracle 函数来检索 操作系统 时区；但是，当您致电 systimestamp.
时，您 可以 看到报告
另一方面，dbtimezone 几乎是一个 任意 时区，在创建数据库时设置；通常它被设置为 UTC (GMT)。它不用于 任何东西 除了数据类型 timestamp with LOCAL time zone 的值 - 这些值被转换为“数据库”时区并作为没有时区组件的时间戳存储在磁盘上, 那个时区.
dbtimezone只需要与自身保持一致即可——与服务器上操作系统的时区完全无关。您可以随意更改数据库时区 - except 当数据库中的表的列类型为 timestamp with LOCAL time zone 并且并非所有这些列都为空时。
这意味着 dbtimezone 毫无意义；它并没有真正控制任何东西。与systimestamp无关，没有简单显示服务器操作系统时区的功能
所以，回到我在顶部所说的……如果文档……会更好吗？
您可能想检查服务器上的当前时间戳（如果您有权访问它），and/or 直接检查其时区。例如，您可能会发现它设置为与 UTC 的固定偏移量，因此它可能不会反映夏令时。管他呢。但这是您应该查看的正确“事物”，与 current_timestamp 和 sessiontimezone 进行比较。你如何在服务器上执行此操作（即使假设你可以访问它）将取决于操作系统 - Windows、Linux、Unix 等。无论如何，你的 systimestamp 显示'-03:00` 就好像它是与 UTC 的固定偏移量。
编辑 - 进一步研究，如果我理解正确的话，巴西选择了一个特殊的（？？）今年不遵守夏令时。因此，-03:00 偏移量似乎是正确的。根据您报告的值，Oracle 似乎并不知道这一点，并且将“America/Sao_Paulo”视为受 DST 影响。这就是为什么 systimestamp 是正确的，而 current_timestamp 偏差一小时。
要么 Oracle 不“知道”这件事，要么它知道并且它发布了一个尚未应用到您的系统的补丁。管他呢。很明显，服务器上的操作系统确实知道这一点。问题出在数据库中，与“db”或“session”时区无关（因为它们相同），而是时区本身，以及它在这个特殊年份的意义。
为了它的价值，我刚刚在我的系统上进行了测试 - 如果我 select systimestamp at time zone '-03:00' 我得到了正确的圣保罗当前时间（在线检查）；如果我将时区更改为 'America/Sao_Paulo' 我会晚一个小时。这是预料之中的 - 我的系统没有打补丁（我不是付费客户，我只是玩数据库的“练习”版本，我没有资格获得补丁）。
这是一个反复出现的话题，但我仍然找不到解决方案。据我了解，SYSTIMESTAMP 将 return 基于服务器时区的时间，而 CURRENT_TIMESTAMP 将 return 基于客户端时区。
我正在从家里连接到远程 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 信息，但无法弄清楚我遗漏了什么。有人可以帮忙吗？
如果 Oracle 文档能更清楚地说明这些事情，那就更好了，不是吗？
sys....（如sysdate和systimestamp）是操作系统运行的date-time/timestamp数据库软件（“服务器”）。没有 Oracle 函数来检索 操作系统 时区；但是，当您致电 systimestamp.
另一方面，dbtimezone 几乎是一个 任意 时区，在创建数据库时设置；通常它被设置为 UTC (GMT)。它不用于 任何东西 除了数据类型 timestamp with LOCAL time zone 的值 - 这些值被转换为“数据库”时区并作为没有时区组件的时间戳存储在磁盘上, 那个时区.
dbtimezone只需要与自身保持一致即可——与服务器上操作系统的时区完全无关。您可以随意更改数据库时区 - except 当数据库中的表的列类型为 timestamp with LOCAL time zone 并且并非所有这些列都为空时。
这意味着 dbtimezone 毫无意义；它并没有真正控制任何东西。与systimestamp无关，没有简单显示服务器操作系统时区的功能
所以，回到我在顶部所说的……如果文档……会更好吗？
您可能想检查服务器上的当前时间戳（如果您有权访问它），and/or 直接检查其时区。例如，您可能会发现它设置为与 UTC 的固定偏移量，因此它可能不会反映夏令时。管他呢。但这是您应该查看的正确“事物”，与 current_timestamp 和 sessiontimezone 进行比较。你如何在服务器上执行此操作（即使假设你可以访问它）将取决于操作系统 - Windows、Linux、Unix 等。无论如何，你的 systimestamp 显示'-03:00` 就好像它是与 UTC 的固定偏移量。
编辑 - 进一步研究，如果我理解正确的话，巴西选择了一个特殊的（？？）今年不遵守夏令时。因此，-03:00 偏移量似乎是正确的。根据您报告的值，Oracle 似乎并不知道这一点，并且将“America/Sao_Paulo”视为受 DST 影响。这就是为什么 systimestamp 是正确的，而 current_timestamp 偏差一小时。
要么 Oracle 不“知道”这件事，要么它知道并且它发布了一个尚未应用到您的系统的补丁。管他呢。很明显，服务器上的操作系统确实知道这一点。问题出在数据库中，与“db”或“session”时区无关（因为它们相同），而是时区本身，以及它在这个特殊年份的意义。
为了它的价值，我刚刚在我的系统上进行了测试 - 如果我 select systimestamp at time zone '-03:00' 我得到了正确的圣保罗当前时间（在线检查）；如果我将时区更改为 'America/Sao_Paulo' 我会晚一个小时。这是预料之中的 - 我的系统没有打补丁（我不是付费客户，我只是玩数据库的“练习”版本，我没有资格获得补丁）。