Timestamp with Time Zone数据类型具有此怪异的功能,当我们选择时格式时,它保留了从插入时区开始的格式;
使用TZR
UPDATE X SET COLUMN_A = TO_TIMESTAMP_TZ('19-JUL-18 01.53.16.381566000 PM UTC',
'DD-MON-RR HH.MI.SSXFF AM TZR') ...
如果我直接选择此列;
> SELECT COLUMN_A WHERE ...
19-JUL-18 01.53.16.381566000 PM UTC
使用TZH:TZM
UPDATE X SET COLUMN_A = TO_TIMESTAMP_TZ('19-JUL-18 01.53.16.381566000 PM +00:00',
'DD-MON-RR HH.MI.SSXFF AM TZH:TZM') ...
如果我直接选择此列;
> SELECT COLUMN_A WHERE ...
19-JUL-18 01.53.16.381566000 PM +00:00
此功能背后的原因是什么,有没有办法控制这种方式,例如,我可以将所有此类值设置为TZH:TZM
格式。我并不是在谈论特定于会话的NLS_TIMESTAMP_TZ_FORMAT
,尽管它在SELECT
情况下非常有用
答案 0 :(得分:1)
我遇到了您的问题,但我仍然认为这取决于工具。在我的蟾蜍中,以下测试用例返回相同的结果:
create table test_a(
id number,
column_a timestamp with time zone
)
;
insert into test_a(id) values(1);
insert into test_a(id) values(2);
update test_a
SET COLUMN_A = TO_TIMESTAMP_TZ('19-JUL-18 01.53.16.381566000 PM UTC',
'DD-MON-RR HH.MI.SSXFF AM TZR')
where id = 1;
update test_a
SET COLUMN_A = TO_TIMESTAMP_TZ('19-JUL-18 01.53.16.381566000 PM +00:00',
'DD-MON-RR HH.MI.SSXFF AM TZH:TZM')
where id = 2;
select * from test_a;
ID COLUMN_A
---------- -----------------------------------
COLUMN_B
-----------------------------------
1 2018-07-19 13:53:16.381566 +00:00
2 2018-07-19 13:53:16.381566 +00:00
2 rows selected.
答案 1 :(得分:1)
时区UTC
与时区+00:00
不同。您只需得到之前插入的内容即可。
当我说“时区Europe/Zurich
与时区+02:00
不同时,答案可能会更加清楚。”目前,两者都比UTC提前2小时,因此两者相等。但是在冬季,这种情况将会改变。
UTC
和+00:00
都不适用夏令时,因此差异并不明显,但在内部却有所不同。