I got a column with the following timestamp format currently stored as varchar2:
31DEC2019 13:20:51,847
I don't really recognize this format, and I have a hard time writing a mask that captures the values. I have tried using this, and variations of it:
'DDMONYYYY HH:MIN:SSFF3'
But no luck. Any ideas? My goal is to convert the column from varchar2, to timestamp
This should be the right format:
'DDMONYYYY HH24:MI:SS,FF3'
Here we have:
DD: day
MON month
YYYY year
HH24: hour in 24-hours format
MI: MInutes
SS: seconds
,: the separator
FF3 milliseconds
This assumes that your strings represent timestamps in the language that your session is using; for example, say you have that value stored, if you work wiat a session in English language, everything works:
SQL> alter session set nls_language='English';
Session altered.
SQL> select to_timestamp('31DEC2019 13:20:51,847', 'DDMONYYYY HH24:MI:SS,FF3') as t from dual;
T
---------------------------------------------------------------------------
31-DEC-19 01.20.51.847000000 PM
1 row selected.
With the same data, a different session language can give errors:
SQL> alter session set nls_language='Italian';
Modificata sessione.
SQL> select to_timestamp('31DEC2019 13:20:51,847', 'DDMONYYYY HH24:MI:SS,FF3') as t from dual;
select to_timestamp('31DEC2019 13:20:51,847', 'DDMONYYYY HH24:MI:SS,FF3') as t from dual
*
ERRORE alla riga 1:
ORA-01843: mese non valido
This happens because, in the example, 'December' is 'Dicembre' in Italian, so the month part should be 'DIC' and not 'DEC'.
No matter the session language, if you know that data are stored in English, or whatever other language, you can force the usage of the needed language in the to_timestamp call:
SQL> select to_timestamp('31DEC2019 13:20:51,847', 'DDMONYYYY HH24:MI:SS,FF3', 'NLS_DATE_LANGUAGE = English') as t from dual;
T
---------------------------------------------------------------------------
31-DIC-19 01.20.51.847000000 PM
1 riga selezionata.
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.
I'm creating tables in Oracle 11g table and came across one date field of format "YYYY-MM-DD".
I don't want to use varchar2 for this and when I use number(5), it's still accepting the input. Then what's the meaning of limit 5 here?
Please suggest me the best datatype I can use here.
This is, obviously, a date format mask. If you're about to store dates into that column, you should use the DATE datatype, such as
SQL> create table test
2 (datum date);
Table created.
Don't use VARCHAR2 (put strings into it, not dates) nor NUMBER (put numbers into it, not dates) datatypes for that. You'll regret it sooner than you think.
I'm going to enter some values into the table, showing different ways of how you could do that - it is important that you insert dates, not strings into it. Never rely on Oracle, implicitly converting strings you might provide to dates. Sooner or later, it'll produce an error.
SQL> insert into test values (date '2018-12-25');
1 row created.
SQL> insert into test values (to_date('09.05.2018', 'dd.mm.yyyy'));
1 row created.
SQL> insert into test values (sysdate);
1 row created.
Now, several ways of selecting that value:
This one returns date in a format currently set by my database's NLS settings:
SQL> select * from test;
DATUM
--------
25.12.18
09.05.18
09.05.18
I'm forcing it to return values in desired format, using ALTER SESSION:
SQL> alter session set nls_date_format = 'yyyy-mm-dd';
Session altered.
SQL> select * from test;
DATUM
----------
2018-12-25
2018-05-09
2018-05-09
Yet another format; note that value inserted via the SYSDATE function (which returns DATE) contains date and time component. It was "invisible" in previous examples:
SQL> alter session set nls_date_format = 'dd.mm.yyyy hh24:mi:ss';
Session altered.
SQL> select * from test;
DATUM
-------------------
25.12.2018 00:00:00
09.05.2018 00:00:00
09.05.2018 08:03:50
Using TO_CHAR function with some format (such as dd-mon-yyyy). I'm also requesting Oracle to "translate" month name into English (as my database works in Croatian):
SQL> select to_char(datum, 'dd-mon-yyyy', 'nls_date_language = english') datum from test;
DATUM
-----------
25-dec-2018
09-may-2018
09-may-2018
SQL>
[EDIT]
Oracle doesn't store DATE values in any "human" readable format (there's more to read on the Internet, Google for it). It is a format mask that represents that value to you.
I strongly suggest you NOT to store dates into any datatype column but DATE. It's a time bomb, waiting to explode (and then it'll hurt). Nobody stops you from entering a value as '1234-99-66' or '12-345-678'; what will you do with it, then?
Consider creating a view on a top of the table which uses TO_CHAR function and returns the value in a format you want ('yyyy-mm-dd'). DATE datatype column in a table makes sure that values are valid, and the view will let the third-party application to accept values it finds appropriate.
For example:
SQL> create view v_test as
2 select to_char(datum, 'yyyy-mm-dd') datum
3 from test;
View created.
SQL> select * from v_test;
DATUM
----------
2018-12-25
2018-05-09
2018-05-09
SQL>
So: you wouldn't let the third-party application to access the table, but the view instead.
I'm trying to set a value in an Oracle database that resembles the following:
2016-06-21 03:07:25.0
It is a varchar of the current date with one digit after the decimal for seconds. I tried multiple ways to achieve this but to no avail:
SQL> select sysdate from dual;
SYSDATE
--------
21-06-16
From this I tried:
SQL> alter session set nls_date_format='YYYY-MM-DD HH24:MI:SS.F';
ERROR:
ORA-01821: date format not recognized
SQL> alter session set nls_date_format='YYYY-MM-DD HH24:MI:SS.s';
ERROR:
ORA-01821: date format not recognized
Then I tried:
SQL> SELECT TO_CHAR(SYSDATE,'YYYY-MM-DD HH24:MI:SS') FROM dual;
TO_CHAR(SYSDATE,'YY
-------------------
2016-06-21 12:58:55
Since that worked up to the seconds I tried the decimal part:
SQL> SELECT TO_CHAR(SYSDATE,'YYYY-MM-DD HH24:MI:SS.SSSS') from dual;
TO_CHAR(SYSDATE,'YYYY-MM
------------------------
2016-06-21 13:23:47.4747
So I can get 4 significant places. Now I try with just 1:
SQL> SELECT TO_CHAR(SYSDATE,'YYYY-MM-DD HH24:MI:SS.S') from dual;
SELECT TO_CHAR(SYSDATE,'YYYY-MM-DD HH24:MI:SS.S') from dual
*
ERROR at line 1:
ORA-01821: date format not recognized
So how can I get the current timestamp in the abovementioned format with seconds set to one decimal place?
SSSS isn't fractional seconds. It's just repeating the SS value twice; in your example you get 13:23:47.4747 - the 4747 is just 47 displayed twice. Maybe you were thinking of SSSSS, but that is the number of seconds since midnight (i.e. 0-86399) so isn't useful here either. A single S isn't a valid format model element.
Dates don't have fractional second precision. A single F isn't a valid format model element either, but even FF isn't valid for a date.
You need to use systimestamp to get the server time with fractional seconds, rather than sysdate:
select to_char(systimestamp, 'YYYY-MM-DD HH24:MI:SS.FF1') from dual;
TO_CHAR(SYSTIMESTAMP,'YYYY-MM
-----------------------------
2016-06-21 14:42:22.7
Storing a date/time as a string is generally a bad idea. I'd suggest you make the column timestamp(1) which will keep the one-decimal-place precision when you set it from systimestamp. You can see what it would get with cast:
select to_char(cast(systimestamp as timestamp(1)), 'YYYY-MM-DD HH24:MI:SS.FF9') from dual;
TO_CHAR(CAST(SYSTIMESTAMPASTI
-----------------------------
2016-06-21 14:49:09.900000000
Converting a date/time to a string should really only be done for display, not for storage.
I have inherited an Oracle .dmp file which I'm trying to get into CSV so that I can load it into MySQL.
The general approach I'm using is described here. I'm having a problem with one row though. It contains a date of 5544-09-14 like so:
alter session set nls_date_format = 'dd-MON-yyyy';
select OID, REF, TRADING_DATE From LOAN WHERE REF = 'XXXX';
OID REF TRADING_DATE
--- -------------------- ------------
1523 XXXX 14-SEP-5544
This is garbage data from the legacy system which didn't validate the input dates. I'm wondering why my PL/SQL function to export the data chokes on this value though?
It exports that row with a TRADING_DATE value of '0000-00-00T00:00:00' and I'm not sure why?
SELECT dump(TRADING_DATE) FROM LOAN WHERE REF = 'XXXX';
DUMP(TRADING_DATE)
--------------------------------------------------------------------------------
Typ=12 Len=7: 44,156,9,14,1,1,1
and
SELECT to_char(trading_date, 'YYYYMMDDHH24MISS') FROM LOAN WHERE REF = 'XXXX';
TO_CHAR(TRADIN
--------------
00000000000000
The value stored in that column is not a valid date. The first byte of the dump should be the century, which according to Oracle support note 69028.1 is stored in 'excess-100' notation, which means it should have a value of 100 + the actual century; so 1900 would be 119, 2000 would be 120, and 5500 would be 155. So 44 would represent -5600; the date you have stored appears to actually represent 5544-09-14 BC. As Oracle only supports dates with years between -4713 and +9999, this isn't recognised.
You can recreate this fairly easily; the trickiest bit is getting the invalid date into the database in the first place:
create table t42(dt date);
Table created.
declare
d date;
begin
dbms_stats.convert_raw_value('2c9c090e010101', d);
insert into t42 (dt) values (d);
end;
/
PL/SQL procedure successfully completed.
select dump(dt), dump(dt, 1016) from t42;
DUMP(DT)
--------------------------------------------------------------------------------
DUMP(DT,1016)
--------------------------------------------------------------------------------
Typ=12 Len=7: 45,56,9,14,1,1,1
Typ=12 Len=7: 2d,38,9,e,1,1,1
So this has a single row with the same data you do. Using alter session I can see what looks like a valid date:
alter session set nls_date_format = 'DD-Mon-YYYY';
select dt from t42;
DT
-----------
14-Sep-5544
alter session set nls_date_format = 'YYYYMMDDHH24MISS';
select dt from t42;
DT
--------------
55440914000000
But if I use an explicit date mask it just gets zeros:
select to_char(dt, 'DD-Mon-YYYY'), to_char(dt, 'YYYYMMDDHH24MISS') from t42;
TO_CHAR(DT,'DD-MON-Y TO_CHAR(DT,'YY
-------------------- --------------
00-000-0000 00000000000000
And if I run your procedure:
exec dump_table_to_csv('T42');
The resultant CSV has:
"DT"
"0000-00-00T00:00:00"
I think the difference is that those that attempt to show the date are sticking with internal date data type 12, while those that show zeros are using external data type 13, as mentioned in note 69028.1.
So in short, your procedure isn't doing anything wrong, the date it's trying to export is invalid internally. Unless you know what date it was supposed to be, which seems unlikely given your starting point, I don't think there's much you can do about it other than guess or ignore it. Unless, perhaps, you know how the data was inserted and can work out how it got corrupted.
I think it's more likely to be from an OCI program than what I did here; this 'raw' trick was originally from here. You might also want to look at note 331831.1. And this previous question is somewhat related.