sql - TIMESTAMP、TIMESTAMP with TIME ZONE 和 TIMESTAMP with LOCAL TIME ZONE 之间的区别

Question

我在两个不同的数据库中运行了相同的语句:我的本地数据库和 Oracle Live SQL .

CREATE TABLE test(
    timestamp TIMESTAMP DEFAULT SYSDATE,
    timestamp_tmz TIMESTAMP WITH TIME ZONE DEFAULT SYSDATE,
    timestamp_local_tmz TIMESTAMP WITH LOCAL TIME ZONE DEFAULT SYSDATE
);

INSERT INTO test VALUES (DEFAULT, DEFAULT, DEFAULT);

SELECT * FROM test;

(所有语句大约在同一时间执行 - 欧洲中部时间上午 09:35)

本地数据库的结果:

TIMESTAMP: 10-JAN-23 09.35.32.000000000 AM
TIMESTAMP WITH TIME ZONE: 10-JAN-23 09.35.32.000000000 AM EUROPE/BERLIN
TIMESTAMP WITH LOCAL TIME ZONE: 10-JAN-23 09.35.32.000000000 AM

Oracle Live 的结果:

TIMESTAMP: 10-JAN-23 08.35.44.000000 AM 
TIMESTAMP WITH TIME ZONE: 10-JAN-23 08.35.44.000000 AM US/PACIFIC   
TIMESTAMP WITH LOCAL TIME ZONE: 10-JAN-23 08.35.44.000000 AM

看到结果后，我的问题是:

• 为什么 Oracle Live 的 TIMESTAMP 显示不同时区的日期(上午 8.35，而不是上午 9.35)？
• 为什么 Oracle Live 的 TIMESTAMP WITH TIME ZONE 返回 US/PACIFIC 作为时区？
• TIMESTAMP 和 TIME STAMP with LOCAL TIME ZONE 之间有什么区别吗？

Answer 1

不同的数据类型是described in the documentation .

The TIMESTAMP data type is an extension of the DATE data type. It stores year, month, day, hour, minute, and second values. It also stores fractional seconds, which are not stored by the DATE data type.

TIMESTAMP WITH TIME ZONE is a variant of TIMESTAMP that includes a time zone region name or time zone offset in its value.

TIMESTAMP WITH LOCAL TIME ZONE is another variant of TIMESTAMP. It differs from TIMESTAMP WITH TIME ZONE as follows: data stored in the database is normalized to the database time zone, and the time zone offset is not stored as part of the column data. When users retrieve the data, Oracle Database returns it in the users' local session time zone.

您会看到差异，因为您有不同的时区，并且您将值默认为 SYSDATE ，这是系统DATE .

在本地数据库中，系统时区 ( select dbtimezone from dual ) 似乎基于 CET，而 Live SQL 数据库似乎基于 UTC，正如 Oracle 建议的那样。由于 CET 比 UTC/GMT 早一小时，这就解释了这一小时的差异。

TIMESTAMP value 只是一个简单的转换，即 cast(SYSDATE as TIMESTAMP )，因此您得到的值与查询 SYSDATE 时得到的值相同。直接添加零小数秒。

对于TIMESTAMP WITH TIME ZONE它必须存储一个时区，并且必须从某个地方获取该时区，并且默认情况下它使用您的 session 时区，而不是数据库时区。在您的本地数据库中，这似乎也是 CET，但 Live SQL 将 session 时区默认为美国太平洋时间 - 考虑到 Oracle 所在的位置，这并非不合理。所以现在它正在有效地做 from_tz(cast(SYSDATE as TIMESTAMP), SESSIONTIMEZONE)对于这个值，你在哪里 SESSIONTIMEZONE一个数据库中为 CET，另一个数据库中为 US/Pacific。

对于TIMESTAMP WITH LOCAL TIME ZONE它做同样的事情，但然后将其规范化回数据库时区进行存储(实际上 cast(from_tz(cast(SYSDATE as TIMESTAMP), SESSIONTIMEZONE) at time zone DBTIMEZONE as TIMESTAMP) - 实际上不是内部的，但给了你想法)，并再次从数据库时区转换回 session 时区当它被查询时。

在这两个数据库中，如果您 alter session set time_zone = ...在插入之前，并在查询之前再次设置为不同的值，那么您将看到不同的结果 - 前两列显示的时间部分将保持不变，但 WITH TIME ZONE 的时区将发生变化。 ，时间将更改为 WITH LOCAL TIME ZONE .

fiddle具有不同的 session 时区。

您可以在我上面链接的文档中阅读有关所有这些行为的更多信息。

---

如果您使用SYSTIMESTAMP而不是SYSDATE作为所有列的默认值，那么您将避免隐式转换为 WITH TIME ZONE 到 session 时区。值，并且将始终显示数据库时区。 LOCAL列仍将显示在您的 session 时区中，但它们都代表相同的时间。您还将看到两个数据库之间存在一小时的差异，因为它们具有不同的数据库时区。您可以考虑将纯时间戳默认为 sys_extract_utc(SYSTIMESTAMP) ，或者将它们全部(或至少前两个)默认为 SYSTIMESTAMP at time zone 'UTC' .

fiddle具有 UTC 标准化值。