I've run into a weird situation. Could someone explain why comparison between timestamp and timestamp behaves as below (it depends on session timezone...). In addition outputed values are identical in all cases.
It looks like timestamp inherits timezone from the session for comparison purposes, but for printing it does not?
Queries:
alter session set time_zone = '-6:0';
select cast(systimestamp as timestamp), systimestamp, case when cast(systimestamp as timestamp) < systimestamp then 'timestamp < systm' else 'timestamp >= systm' end as cmp from dual;
alter session set time_zone = '1:0';
select cast(systimestamp as timestamp), systimestamp, case when cast(systimestamp as timestamp) < systimestamp then 'timestamp < systm' else 'timestamp >= systm' end as cmp from dual;
output:
CAST(SYSTIMESTAMPASTIMESTAMP) SYSTIMESTAMP CMP
----------------------------- ----------------------------------- ------------------
14/02/06 21:22:05,319973000 14/02/06 21:22:05,319973000 -06:00 timestamp >= systm
session SET altered.
CAST(SYSTIMESTAMPASTIMESTAMP) SYSTIMESTAMP CMP
----------------------------- ----------------------------------- ------------------
14/02/06 21:22:06,057183000 14/02/06 21:22:06,057183000 -06:00 timestamp < systm
Database is in -6 timezone. Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
Look at this:
https://docs.oracle.com/cd/B12037_01/server.101/b10749/ch4datet.htm#1006334
When you compare date and timestamp values, Oracle converts the data to the more precise datatype before doing the comparison. For example, if you compare data of TIMESTAMP WITH TIME ZONE datatype with data of TIMESTAMP datatype, Oracle converts the TIMESTAMP data to TIMESTAMP WITH TIME ZONE, using the session time zone.
The order of precedence for converting date and timestamp data is as follows:
1. DATE
2. TIMESTAMP
3. TIMESTAMP WITH LOCAL TIME ZONE
4. TIMESTAMP WITH TIME ZONE
For any pair of datatypes, Oracle converts the datatype that has a smaller number in the preceding list to the datatype with the larger number.
SYSTIMESTAMP returns a TIMESTAMP WITH TIME ZONE datatype. Looks like Oracle converts the TIMESTAMP to an TIMESTAMP WITH TIME ZONE datatype for comparison, actualy Oracle performs this:
SELECT
CASE
WHEN CAST(CAST(SYSTIMESTAMP AS TIMESTAMP) AS TIMESTAMP WITH TIME ZONE) < SYSTIMESTAMP
THEN 'timestamp < systm'
ELSE 'timestamp >= systm'
END AS cmp
FROM dual;
For conversion it takes the SESSION Timezone, you can check it with this query:
SELECT
EXTRACT(TIMEZONE_HOUR FROM CAST(CAST(SYSTIMESTAMP AS TIMESTAMP) AS TIMESTAMP WITH TIME ZONE)) AS TZ_HOUR
FROM dual;
You can discuss if this makes sense or not. For a correct conversion you better use FROM_TZ function, then it is under your control. SYSTIMESTAMP returns timestamp in DB timezone, so proper statement would be this one:
SELECT FROM_TZ(LOCALTIMESTAMP, DBTIMEZONE), SYSTIMESTAMP,
CASE FROM_TZ(LOCALTIMESTAMP, DBTIMEZONE) < SYSTIMESTAMP THEN
...
Related
According to the H2 documentation, in the Oracle compatibility mode:
DATE data type is treated like TIMESTAMP(0) data type.
Meantime, DATE and TIMESTAMP(0) datatypes are not the same in Oracle. Compare:
SELECT CAST(SYSDATE AS TIMESTAMP(0)), CAST(SYSDATE AS DATE) from dual
gives
25-MAR-22 13.07.42.000000000 25-MAR-22
respectively.
In particular, this weird treating of DATE as TIMESTAMP(0) influences on how H2 calculates the difference between two dates.
Again, in Oracle:
SELECT CAST(TO_DATE('2022-01-05', 'YYYY-MM-DD') AS TIMESTAMP(0)) - CAST(TO_DATE('2022-01-01', 'YYYY-MM-DD') AS TIMESTAMP(0)) from dual
gives
+04 00:00:00.000000
and
SELECT CAST(TO_DATE('2022-01-05', 'YYYY-MM-DD') AS DATE) - CAST(TO_DATE('2022-01-01', 'YYYY-MM-DD') AS DATE) from dual
produces just:
4
Apparently, for H2 both above queries produce the result in nanoseconds and not days as expected.
So, it is an H2 bug or I am missing something?
Meantime, DATE and TIMESTAMP(0) datatypes are not the same in Oracle
Oracle differs from many other RDBMS in that its DATE data type ALWAYS contains both a date and a time component. Its implementation predates the ANSI standard.
In Oracle, if you have the table:
CREATE TABLE table_name (ts TIMESTAMP(0), dt DATE);
and insert the data:
INSERT INTO table_name (ts, dt) VALUES (SYSDATE, SYSDATE);
Then you can look at the binary data being stored using the DUMP function:
SELECT DUMP(ts) AS dump_ts,
DUMP(dt) AS dump_dt
FROM table_name;
Which outputs:
DUMP_TS
DUMP_DT
Typ=180 Len=7: 120,122,3,25,15,13,37
Typ=12 Len=7: 120,122,3,25,15,13,37
Then you can see that they are both stored as 7-byte binary values:
120 = Century + 100
122 = Year-of-century + 100
3 = Month
25 = Day
15 = Hour + 1
13 = Minutes + 1
37 = Seconds + 1
And the binary values are identical (the only difference is in the meta-data Typ where 180 = TIMESTAMP and 12 = DATE).
Effectively, they are stored identically.
db<>fiddle here
However
The side-effects of a TIMESTAMP vs. a DATE data type in Oracle may lead to different effects.
When you subtract a TIMESTAMP and either a TIMESTAMP or a DATE then the return value is an INTERVAL DAY TO SECOND data type.
When you subtract a DATE and a DATE then the default return value is a NUMBER representing the number of days difference.
When you display a TIMESTAMP then the client application you are using may default to using the NLS_TIMESTAMP_FORMAT session parameter to format the timestamp as a string and the default for this parameter will typically show date, time and fractional seconds.
When you display a DATE then the client application you are using may default to using the NLS_DATE_FORMAT session parameter to format the date as a string and the default for this parameter will show date but not time (and there will never be any fractional seconds to show). Just because the client application may chose not to show the time component does not mean that the time component does not exist.
If you set the session parameters using:
ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS';
ALTER SESSION SET NLS_TIMESTAMP_FORMAT = 'YYYY-MM-DD HH24:MI:SS';
Then, provided your client application is using those parameters to format them, they will display identically.
The problem you are seeing with the difference in Oracle is due to these side effects.
If the question is
So, it is an H2 bug or I am missing something?
than the the answer would be:
No, it is not a bug, and what you've missed is the fact, that compatibility modes in H2 are just that - attempt to reach with minimal efforts maximum compatibility with different databases.
H2 is not an emulator for any non-standard features (quirks) of those databases.
It that particular case, to achieve identical behaviour would require to introduce new non-standard data type, which goes beyond "minimal effort" level.
The different in the output of the values in the first query is down to the session's NLS settings. These control the display format for dates and timestamps:
sho parameter nls_date_format
NAME TYPE VALUE
--------------- ------ -----------
nls_date_format string DD-MON-YYYY
sho parameter nls_timestamp_format
NAME TYPE VALUE
-------------------- ------ -------------------------
nls_timestamp_format string DD-MON-YYYY HH24.MI.SSXFF
SELECT CAST(SYSDATE AS TIMESTAMP(0)), CAST(SYSDATE AS DATE) from dual;
CAST(SYSDATEASTIMESTAMP(0)) CAST(SYSDAT
------------------------------ -----------
25-MAR-2022 12.18.24.000000000 25-MAR-2022
If you change these to be the same format, both expressions return the same result:
alter session set nls_date_format = 'DD-MON-YYYY HH24:MI:SS';
alter session set nls_timestamp_format = 'DD-MON-YYYY HH24:MI:SS';
SELECT CAST(SYSDATE AS TIMESTAMP(0)), CAST(SYSDATE AS DATE) from dual;
CAST(SYSDATEASTIMEST CAST(SYSDATEASDATE)
-------------------- --------------------
25-MAR-2022 12:17:43 25-MAR-2022 12:17:43
So they both contain the full date + time with no fractional seconds.
Note that while date and timestamp(0) have the same precision, as your further examples show they work differently:
Subtracting one date from another returns the number of days between the values as a number
Subtracting a timestamp from a date or timestamp returns an interval
So the result of:
SELECT CAST(TO_DATE('2022-01-05', 'YYYY-MM-DD') AS DATE) - CAST(TO_DATE('2022-01-01', 'YYYY-MM-DD') AS DATE) from dual
Is 4 days.
I need to convert below timezone format in the following format:
Input:
2020-10-28T20:12:20.986Z
Output:
28-OCT-20 8:12 PM
I tried below query but I am unable to get timestamp with it. Please help.
select TO_TIMESTAMP(SUBSTR('2020-04-21T13:02:31.259Z',1,(INSTR('2020-04-21T13:02:31.259Z', 'T') - 1)),'YYYY-MM-DD HH24:MI:SS') from dual;
One option might be this
SQL> alter session set nls_timestamp_format = 'dd-MON-YY hh:mi PM' ;
Session altered.
SQL> select to_timestamp('2020-10-28T20:12:20.986Z','yyyy-mm-dd"T"hh24:mi:ss.ff3"Z"') from dual ;
TO_TIMESTAMP('2020-10-28T20:12:20.986Z','YYYY-MM-DD"T"HH24:MI:SS.FF3"Z"')
---------------------------------------------------------------------------
28-OCT-20 08:12 PM
SQL>
But if you rely better in the to_timestamp function without any session setting, then it is better
SQL> select to_timestamp('2020-10-28T20:12:20.986Z','yyyy-mm-dd"T"hh24:mi:ss.ff3"Z"') from dual ;
TO_TIMESTAMP('2020-10-28T20:12:20.986Z','YYYY-MM-DD"T"HH24:MI:SS.FF3"Z"')
---------------------------------------------------------------------------
28-OCT-20 08.12.20.986000000 PM
You have a timestamp string with a time zone, use TO_TIMESTAMP_TZ rather than TO_TIMESTAMP and then use TO_CHAR to format it:
SELECT TO_CHAR(
TO_TIMESTAMP_TZ(
'2020-04-21T13:02:31.259Z',
'YYYY-MM-DD"T"HH24:MI:SS.FFTZR'
),
'DD-MON-RR HH12:MI AM',
'NLS_DATE_LANGUAGE=American'
)
FROM DUAL;
db<>fiddle here
Note: DATE, TIMESTAMP and TIMESTAMP WITH TIME ZONE are binary data types and are stored in 7-20 bytes (1 byte each for century, year-of-century, month, day, hour, minute and second then up to 6 optional bytes for fractional seconds for TIMESTAMPs and up to 7-bytes for time zone for TIMESTAMP WITH TIME ZONE). It is never stored in any particular format.
How the DATE/TIMESTAMP data types are displayed is dependent on the client application that you are using to query the database; some may use the NLS settings for the user's session but others do not use that. If you want a particular format then convert the DATE/TIMESTAMP to a string using TO_CHAR.
In Oracle database I have this table (the data type of column col is DATE):
col
2021-02-26 23:14:24
Question: in my case, assuming over time DB settings haven't changed, which time zone does the table's column of DATE data type reflect?
UTC or
Europe/Helsinki?
Following I provide current DB settings.
Database time zone
SELECT DBTIMEZONE FROM DUAL;
|DBTIMEZONE |
|============|
|+00:00 |
Session time zone
SELECT SESSIONTIMEZONE FROM DUAL;
|SESSIONTIMEZONE|
|===============|
|Europe/Helsinki|
SELECT CURRENT_DATE FROM DUAL;
|CURRENT_DATE |
|===================|
|2021-07-18 15:05:32|
The time zone of database server's operating system
SELECT SYSDATE FROM DUAL;
|SYSDATE |
|===================|
|2021-07-18 15:05:32|
SELECT SYSTIMESTAMP FROM DUAL;
|SYSTIMESTAMP |
|==============================|
|2021-07-18 15:05:32.984 +03:00|
The time zone is undefined by the column.
You can do:
CREATE TABLE table_name (col DATE);
ALTER SESSION SET TIME_ZONE = 'UTC';
INSERT INTO table_name (col) VALUES (CURRENT_DATE);
ALTER SESSION SET TIME_ZONE = 'Europe/Helsinki';
INSERT INTO table_name (col) VALUES (CURRENT_DATE);
ALTER SESSION SET TIME_ZONE = 'America/New_York';
INSERT INTO table_name (col) VALUES (CURRENT_DATE);
Then:
ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS';
SELECT * FROM table_name;
Outputs:
COL
2021-07-18 21:06:05
2021-07-19 00:06:05
2021-07-18 17:06:05
db<>fiddle here
Those values were all inserted in the same second by the same user in the same session using identical SQL statements; however there is no consistency in the time zone of the DATE value as the session settings were altered between each statement; so you cannot rely on a DATE having any particular time zone.
If you want to work out what time zone your data is in then check your application that is storing the data:
Is it always using SYSDATE? Then the time zone of the column is the time zone of the database's system.
Does the application specify the time zone? Then the data will have the time zone specified by the application.
Is it taking data from an external source? Then check that external source.
Is it taking data from the user? Then you have no guarantees.
If the data is of type DATE, then it doesn't reflect any time zone at all. It's just a date and time, with time resolved to the second. SYSDATE simply gets date and time from the host server OS, so to the degree that the time portion is reflective of any time zone, it would be that of the host OS.
I have this time format:
2020-09-08 14:00:00
and I want to convert it to following which is from Sydney time to UTC:
2020-09-08T01:00:00Z
First of all, giving the answer considering that your data is actual varchar2:
SQL> SELECT TO_CHAR(CAST(TO_DATE('2020-09-08 14:00:00','YYYY-MM-DD HH24:MI:SS')
2 AS TIMESTAMP) AT TIME ZONE 'Australia/Sydney',
3 'YYYY-MM-DD"T"HH24:MI:SS"Z"')
4 FROM DUAL;
TO_CHAR(CAST(TO_DATE
--------------------
2020-09-08T18:30:00Z
SQL>
Please note that You can also set NLS_TIMESTAMP_TZ_FORMAT = 'YYYY-MM-DD"T"HH24:MI:SS"Z"' in your session (and don't use the TO_CHAR in your query) as per your requirement. Also, you can use UTC timezone instead of Australia/Sydney if you want to convert your local date to UTC timezone. DB<>Fiddle for UTC conversion.
If the given data is already in date datatype stored in your table, then you just need to use CAST as follows: (TO_DATE is not required)
SELECT TO_CHAR(CAST(YOUR_DATE_COLUMN
AS TIMESTAMP) AT TIME ZONE 'Australia/Sydney',
'YYYY-MM-DD"T"HH24:MI:SS"Z"')
FROM YOUR_TABLE;
I need to compare date with date of current day, using SYSDATE, something like this:
SELECT * FROM my_table
WHERE date_column BETWEEN TO_DATE(SYSDATE -3,'dd.mm.yyyy') AND TO_DATE(SYSDATE,'dd.mm.yyyy');
However, this produces no result....My question :
Based on accepted answer here we should NEVER EVER compare strings with date. But in other side, a SYSDATE is allready a Date data type, and we should not compare It to a date - see here.
If I replace TO_DATE with TO_CHAR in upper SQL things go working again. But TO_CHAR function converts into String, so Oracle (I pressume) needs to convert this string again to date so you force Oracle to do an implicit data type conversion.
So, what should be a correct comparison with date and SYSDATE, in order to avoid Oracle working a bit slowly ?
You should not need to call either TO_DATE or TO_CHAR:
SELECT *
FROM my_table
WHERE date_column >= TRUNC(SYSDATE - 3) AND date_column < TRUNC(SYSDATE + 1);
Assuming date_column is a date type, you should be able to directly compare it against SYSDATE, or SYSDATE offset by some number of days.