4

I ran

 select SYSDATE from dual;

Output:

SYSDATE            |
-------------------|
2019-10-09 08:55:29|

Then I ran,

SELECT DBTIMEZONE FROM DUAL;

Output:

DBTIMEZONE|
----------|
+00:00    |

In the first output, time is in EST and 2nd output suggests timezone is UTC.

How do I check oracle server timezone via SQL query?

John Rotenstein
  • 241,921
  • 22
  • 380
  • 470
Dev
  • 13,492
  • 19
  • 81
  • 174

2 Answers2

3

From the docs:

The database time zone [DBTIMEZONE] is relevant only for TIMESTAMP WITH LOCAL TIME ZONE columns. Oracle recommends that you set the database time zone to UTC (0:00)...

SYSDATE/SYSTIMESTAMP will return the time in the database server's OS timezone. Selecting a TIMESTAMP WITH LOCAL TIME ZONE datatype will return the time in your session's timezone (ie, SESSIONTIMEZONE).

select 
   CAST(systimestamp AS timestamp(0) with local time zone) as local_time,
   systimestamp as server_time
from dual;

DBTIMEZONE is only used as the base timezone stored in TIMESTAMP WITH LOCAL TIME ZONE columns - which you never see, because when you select from one of those columns it gets translated into your session timezone.

See this similar question for a very detailed answer.

kfinity
  • 8,581
  • 1
  • 13
  • 20
3

It is a common misunderstanding that SYSDATE or SYSTIMESTAMP are returned at DBTIMEZONE

SYSDATE and SYSTIMESTAMP are given in the time zone of database server's operating system. If you like to interrogate the time zone of database server's operating system run

SELECT TO_CHAR(SYSTIMESTAMP, 'tzr') FROM dual;

see also How to handle Day Light Saving in Oracle database

Wernfried Domscheit
  • 54,457
  • 9
  • 76
  • 110
  • SYSDATE is unzoned, it does not contain a timezone, instead the timezone is inferred from the database server's operating system that was in effect when the database was started. SYSTIMESTAMP does contain a timezone. – Chad Nov 29 '22 at 05:10
  • @Chad are you sure? This would require a database restart every time when daylight-saving times switches. – Wernfried Domscheit Nov 29 '22 at 05:28
  • Seems like the doco is very clear about daylight-saving calculations (https://docs.oracle.com/cd/E18283_01/server.112/e10729/ch4datetime.htm#insertedID11) – Chad Nov 29 '22 at 06:29
  • @Chad this does not solve my concerns. I live in Switzerland, `TO_CHAR(SYSTIMESTAMP, 'tzr')` returns `01:00` (not `Europe/Zurich`). One months ago, the same query returned `02:00`, I doubt that the database had been restarted in the meantime, `select to_char(startup_time, 'yyyy-mm-dd hh24:mi:ss') from v$instance;` returns `2020-07-24 20:19:34`. Just as information, `TO_CHAR(SYSTIMESTAMP, 'tzd')` returns `NULL`. – Wernfried Domscheit Nov 29 '22 at 08:31
  • The SYSDATE and SYSTIMESTAMP functions simply performs a system-call to the server Operating System to get the time – the so called “gettimeofday” call. The server OS (Unix) timezone settings influences the time that the OS will pass on to Oracle and returned by SYSDATE and SYSTIMESTAMP. – Chad Nov 30 '22 at 02:22
  • @Chad Ok, but that contradicts to your first comment where you wrote "*the timezone ... that was in effect **when the database was started.***" – Wernfried Domscheit Nov 30 '22 at 06:48
  • How so? If your timezone has daylight saving then your operating system is going to pass the adjusted daylight saving datetime to sysdate or systimestamp. Date and timestamp do not have a timezone, their timezone is assumed to be the same as the operating system timezone. – Chad Nov 30 '22 at 13:50
  • As shown above, the operating system does not provide a time zone name or daylight saving settings, it only provides the **current** offset to UTC (e.g. `01:00`). And this offset is changing twice a year (from `01:00` to `02:00` in case of Switzerland). This is not in line with your first statement "*the timezone ... that was in effect when the database was started.*" You can verify with `TO_CHAR(SYSTIMESTAMP + INTERVAL '180' DAY(3), 'YYYY-MM-DD hh24:mi:ss tzr tzh:tzm')` which returns winter-season time, despite `SYSTIMESTAMP + INTERVAL '180' DAY` is in summer season – Wernfried Domscheit Nov 30 '22 at 16:06
  • 1
    You can compare with `TO_CHAR(FROM_TZ(LOCALTIMESTAMP, 'Europe/Zurich') + INTERVAL '180' DAY(3), 'YYYY-MM-DD hh24:mi:ss tzr tzh:tzm')` which does not use static UTC offset, but proper daylight saving time. – Wernfried Domscheit Nov 30 '22 at 16:11
  • I think you're confusing a UTC Offset vs a Timezone they're not the same thing. A time zone's offset can change throughout the year because of Daylight Saving but a time zone is a place. – Chad Dec 02 '22 at 01:50