Could someone explain to me why the result of
SELECT CEIL(MONTHS_BETWEEN(CURRENT_DATE, TO_DATE('30/11/47'))/12) AS AGE FROM DUAL;
Give a negative number?? (AGE =-29)
In the other hand, the following result is OK (AGE = 61)
SELECT CEIL(MONTHS_BETWEEN(CURRENT_DATE, TO_DATE('30/11/57'))/12) AS AGE FROM DUAL;
I tried to change the default nls_date_format as suggested!
Initially I had
After altering session with nls_date_format, no change!
It gives a negative number because it has incorrectly guessed the century.
Be more specific with your date format and the result will be predicable and correct.
ALTER SESSION SET nls_date_format ='DD-MON-YYYY';
SELECT CEIL(MONTHS_BETWEEN(CURRENT_DATE, TO_DATE('30-NOV-1947'))/12) AS AGE FROM DUAL;
AGE
----------
71
1 row selected.
The reason the 1957 date works as you expect, I think, is because you have your NLS_DATE_FORMAT set to DD\MM\RR which guesses the century differently (iirc it makes it 20 for years less than 50 and 19 from year 50 onwards, instead of YY which always uses 20. Use YYYY and then Oracle doesn't need to guess what you mean.
You must specify the format, e.g. TO_DATE('30/11/47', 'DD-MM-RR')
However does 47 mean 1947?
TO_DATE('30/11/47', 'DD-MM-RR') and TO_DATE('30/11/47', 'DD-MM-YY') will result to 2049-11-30 because 47 is lower than 50 (for RR), resp. YY means current century.
Better use TO_DATE('30/11/1947', 'DD-MM-YYYY')
Related
select (current_date - TO_DATE('20210817124015','YYYYMMDDHH24MISS')) from dual;
Outputs:
0.1229282407407407407407407407407407407407
I want to know how oracle internally achieves this value.
ps: the current_date and the hardcoded date are same, only time is the difference.
CURRENT_DATE returns the current date and time in the user's session time zone.
TO_DATE('20210817124015','YYYYMMDDHH24MISS') returns the date 2021-08-17T12:40:15.
Note: A DATE data type always has year, month, day, hour, minute and second components. However, the user interface you are using may chose not to show all the components.
Subtracting one date from another returns the number of days between the two values.
0.1229282407407407407407407407407407407407 days is:
2.950277778 hours; or
177.016666667 minutes; or
10621 seconds; or
2 hours 57 minutes and 1 second.
So your current date was 2021-08-17T12:40:15 + 10621 seconds or 2021-08-17T15:37:16.
For example:
ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD"T"HH24:MI:SS';
ALTER SESSION SET TIME_ZONE = 'Asia/Samarkand';
SELECT CURRENT_DATE,
TO_DATE('20210817124015','YYYYMMDDHH24MISS') As other_date,
CURRENT_DATE - TO_DATE('20210817124015','YYYYMMDDHH24MISS') as difference,
(CURRENT_DATE - TO_DATE('20210817124015','YYYYMMDDHH24MISS')) DAY TO SECOND
as interval_difference
FROM DUAL;
Outputs:
CURRENT_DATE
OTHER_DATE
DIFFERENCE
INTERVAL_DIFFERENCE
2021-08-17T15:40:01
2021-08-17T12:40:15
.124837962962962962962962962962962962963
+00 02:59:46.000000
db<>fiddle here
Subtracting two dates returns a difference in days.
0.1229282407407407407407407407407407407407 days is
2.9502777777768 hours
177.016666666608 minutes
10621 seconds
Or, put another way, current_date is returning a date value that is 2 hours 57 minutes and 1 second after the hard-coded date. Since the hard-coded date has a time of 12:40:51, that means that current_date has a time of 15:37:52.
I could fix this issue by declaring the variable as DATE and not as VARCHAR.
I have a pre-configured constant varchar2 value in a table.
I have declared lv_constants_config as VARCHAR2 and not as DATE.
I think that is the reason why I am facing problem.
SELECT * FROM constants_config
------------------------------
constant1
---------
01/01/3000
In my PL/SQL code I am retrieving this value as,
SELECT TO_DATE(constant1,'MM/DD/YYYY') --I also tried with RRRR instead of YYYY.
INTO lv_constants_config
FROM constants_config;
I am comparing this value with the value input by the User (from UI).
IF iv_input_date > lv_constants_config
THEN
--do this
ELSE
--do that
END IF;
My problem is 3000 is getting wrongly interpreted as 00.
Eg., 01/01/3000 is getting interpreted as 1st Jan, 2000
01/01/3049 is getting interpreted as 1st Jan, 2049
01/01/3050 is getting interpreted as 1st Jan, 2050
How can I compare dates with century value as it is?
I have a problem that is driving me crazy. I have to query an oracle view that returns some DATETIME values.
The incredible problem is that even if I set the "IS NOT NULL" on the WHERE clause and even if I set the NVL(FECHA_HASTA, FECHA_DESDE), I´m still getting null values!!. How is that possible???
This is the query:
SELECT CUIL as Cuil,
COD_TIPO_CAUSAL as CodTipoCausal,
COD_CONVENIO as CodConvenio,
FECHA_DESDE as FechaDesde,
NVL(FECHA_HASTA, FECHA_DESDE) as FechaHasta
FROM ORGANISMO.VCAUSAL_AUSENCIA
WHERE FECHA_HASTA IS NOT NULL
AND FECHA_HASTA > (SELECT SYSDATE - 180 FROM SYS.DUAL)
AND CUIL IN (SELECT CUIL FROM ORGANISMO.VEMPLEADO WHERE FECHA_EGRESO IS NULL OR FECHA_EGRESO > (SELECT SYSDATE FROM SYS.DUAL))
EDIT:
Here is dump(fecha_hasta, 1016) added:
The dumped values show that the data is corrupt. The internal date format is well-known:
byte 1 - century (excess 100)
byte 2 - year (excess 100)
byte 3 - month
byte 4 - day
byte 5 - hour (excess 1)
byte 6 - minute (excess 1)
byte 7 - seconds (excess 1)
so the fourth byte in the two values that SQL Developer is reporting as null (even though they clearly are not actually null) should not be zero, as there is no day zero.
Based on those rules, 79,9d,2,0,18,3c,3c in hex, which is 121,157,2,0,24,60,60 in decimal, should convert as:
century: 121 - 100 = 21
year: 157 - 100 - 57
month: 2
day: 0
hour: 24 - 1 = 23
minute: 60 - 1 = 59
second: 60 - 1 = 59
or 2157-02-00 23:59:59. Similarly 78,b8,1,0,18,3c,3c converts to 2084-01-00 23:59:59.
Version 18.3 of SQL Developer displays those values, in both the script output and query results windows, as the previous day:
DT DUMPED
------------------- -----------------------------------
01-07-2020 23:59:59 Typ=12 Len=7: 78,78,7,1,18,3c,3c
31-01-2157 23:59:59 Typ=12 Len=7: 79,9d,2,0,18,3c,3c
31-12-2083 23:59:59 Typ=12 Len=7: 78,b8,1,0,18,3c,3c
01-07-2018 00:00:00 Typ=12 Len=7: 78,76,7,1,1,1,1
whereas db<>fiddle shows the zero-day values.
So, since they are not actually null, it's reasonable that is not null and nvl() didn't affect them, and then it's up to the client or application as to how to present them.
The real issue is that you seem to have corrupted data in the tables underlying the view you're querying, so that needs to be investigated and fixed - assuming the invalid values can be safely identified, and you can find out what they should have been in the first place, which might be a struggle. Just filtering them out, either as part of the view or in your query, won't be simple though - unless you can filter out dates in the future. And assuming all the corruption is both that obvious and pushing dates into the future; on some level you have to question the validity of all of those dates... there could be much more subtle corruptions that look OK.
And then whatever process or tool caused the corruption needs to be tracked down and fixed so it doesn't happen again. Lots of things can cause corruption of course, but I believe imp used to have a bug that could corrupt dates and numbers, and OCI programs can too.
SELECT TO_TIMESTAMP('2016-10-01 01:00:01', 'YYYY-MM-DD HH24:MI:SS') from dual;
Gives : 2016-10-01 01:00:01
Here year and month parts are understood for me, but Documentation says about other formats:
"DD" - Day of month (1-31)
"HH24" - Hour of day (0-23)
"MI" - Minute (0-59)
"SS" - Second (0-59)
So, why for example "DD" format returns 01 and not just: 1 ?
For example "MM" format, in same doc described as:
MM - Month (01-12; January = 01) and here everything clearly: January = 01 .
Also, little bit confusing is time parts (for me at least) , because in documentation, range for all begins with 0 but returns result as 00
I've expected from above query, result like this:
2016-10-1 1:0:1
What I missed and don't understood correctly?
First you are passing in two strings: the actual datetime (or timestamp) you want to convert to timestamp datatype, and the format model. Then you call to_timestamp(), and the result is a timestamp. Then you DISPLAY this on screen (through SQLPlus or SQL Developer or whatever). Only strings can be displayed on screen - not numbers, not timestamps, etc. So: somewhere, somehow, your timestamp is converted back to a string.
You either do that explicitly, by calling to_char(.....) around your timestamp, or if you don't, the interface application (SQLPlus, SQL Developer, ...) uses your session's NLS_TIMESTAMP_FORMAT parameter. In that parameter, you can force whatever format model you want. In particular, you can suppress leading zeros with the FM format model modifier.
Without changing your NLS_TIMESTAMP_FORMAT you can see the same effect by using to_char() in the query. Try this:
select to_char(to_date('01-Feb-12', 'dd-Mon-yy'), 'FMdd/mm/yyyy hh24:mi:ss') from dual;
Output: 1/2/2012 0:0:0
I need to add 30 minutes to values in a Oracle date column. I do this in my SELECT statement by specifying
to_char(date_and_time + (.000694 * 31)
which works fine most of the time. But not when the time is on the AM/PM border. For example, adding 30 minutes to 12:30 [which is PM] returns 1:00 which is AM. The answer I expect is 13:00. What's the correct way to do this?
In addition to being able to add a number of days to a date, you can use interval data types assuming you are on Oracle 9i or later, which can be somewhat easier to read,
SQL> ed
Wrote file afiedt.buf
SELECT sysdate, sysdate + interval '30' minute FROM dual
SQL> /
SYSDATE SYSDATE+INTERVAL'30'
-------------------- --------------------
02-NOV-2008 16:21:40 02-NOV-2008 16:51:40
All of the other answers are basically right but I don't think anyone's directly answered your original question.
Assuming that "date_and_time" in your example is a column with type DATE or TIMESTAMP, I think you just need to change this:
to_char(date_and_time + (.000694 * 31))
to this:
to_char(date_and_time + (.000694 * 31), 'DD-MON-YYYY HH24:MI')
It sounds like your default date format uses the "HH" code for the hour, not "HH24".
Also, I think your constant term is both confusing and imprecise. I guess what you did is calculate that (.000694) is about the value of a minute, and you are multiplying it by the number of minutes you want to add (31 in the example, although you said 30 in the text).
I would also start with a day and divide it into the units you want within your code. In this case, (1/48) would be 30 minutes; or if you wanted to break it up for clarity, you could write ( (1/24) * (1/2) ).
This would avoid rounding errors (except for those inherent in floating point which should be meaningless here) and is clearer, at least to me.
UPDATE "TABLE"
SET DATE_FIELD = CURRENT_TIMESTAMP + interval '48' minute
WHERE (...)
Where interval is one of
YEAR
MONTH
DAY
HOUR
MINUTE
SECOND
from http://www.orafaq.com/faq/how_does_one_add_a_day_hour_minute_second_to_a_date_value
The SYSDATE pseudo-column shows the current system date and time. Adding 1 to SYSDATE will advance the date by 1 day. Use fractions to add hours, minutes or seconds to the date
SQL> select sysdate, sysdate+1/24, sysdate +1/1440, sysdate + 1/86400 from dual;
SYSDATE SYSDATE+1/24 SYSDATE+1/1440 SYSDATE+1/86400
-------------------- -------------------- -------------------- --------------------
03-Jul-2002 08:32:12 03-Jul-2002 09:32:12 03-Jul-2002 08:33:12 03-Jul-2002 08:32:13
I prefer using an interval literal for this, because interval '30' minute or interval '5' second is a lot easier to read then 30 / (24 * 60) or 5 / (24 * 60 * 69)
e.g.
some_date + interval '2' hour
some_date + interval '30' minute
some_date + interval '5' second
some_date + interval '2' day
You can also combine several units into one expression:
some_date + interval '2 3:06' day to minute
Adds 2 days, 3 hours and 6 minutes to the date value
The above is also standard SQL and also works in several other DBMS.
More details in the manual: https://docs.oracle.com/database/121/SQLRF/sql_elements003.htm#SQLRF00221
If the data type of the field is date or timestamp, Oracle should always give the correct result if you add the correct number given in number of days (or a the correct fraction of a day in your case). So if you are trying to bump the value in 30 minutes, you should use :
select field + 0.5/24 from table;
Based on the information you provided, I believe this is what you tried to do and I am quite sure it works.
Can we not use this
SELECT date_and_time + INTERVAL '20:00' MINUTE TO SECOND FROM dual;
I am new to this domain.
like that very easily
i added 10 minutes to system date and always in preference use the Db server functions not custom one .
select to_char(sysdate + NUMTODSINTERVAL(10,'MINUTE'),'DD/MM/YYYY HH24:MI:SS') from dual;
Be sure that Oracle understands that the starting time is PM, and to specify the HH24 format mask for the final output.
SELECT to_char((to_date('12:40 PM', 'HH:MI AM') + (1/24/60) * 30), 'HH24:MI') as time
FROM dual
TIME
---------
13:10
Note: the 'AM' in the HH:MI is just the placeholder for the AM/PM meridian indicator. Could be also 'PM'
Oracle now has new built in functions to do this:
select systimestamp START_TIME, systimestamp + NUMTODSINTERVAL(30, 'minute') end_time from dual
Based on what you're asking for, you want the HH24:MI format for to_char.
To edit Date in oracle you can try
select to_char(<columnName> + 5 / 24 + 30 / (24 * 60),
'DD/MM/RRRR hh:mi AM') AS <logicalName> from <tableName>
SELECT to_char(sysdate + (1/24/60) * 30, 'dd/mm/yy HH24:MI am') from dual;
simply you can use this with various date format....