To_date('2008','yyyy') = April 1, 2008

I just found this out.
I have been using it thinking it would be January 1st for quite a while. I can see it being useful, but I can't see where it is documented - is it an NLS_ setting?
Jon

I personally wouldn't rely on any assumptions when you're using to_date on a string, other than if you don't supply hours, minutes or seconds, they'll be set to 0.
If you're after just the year, try trunc(<your date>, 'yyyy') - that will set it to 1st Jan at midnight of the year in the date passed in.

Similar Messages

Conversion bug of to_date(x,yyyy/mm/dd)

Dear Madam or Sir,
my name is Christian Butzke and I am working for Perpetuum Co. Ltd. in Japan.
I am using Oracle Database 9. I encountered maybe a bug of the to_date sql function.
I am not sure where to post bug reports. I search one hour on the Oracle homepage for an email address, but there was none, so I tried this forum. If this forum does not handle bugs, I am sorry.
The following script should show after each select command one row with 2005-01-01 00:00:00.0.
CREATE TABLE test ("df" DATE);
INSERT INTO test VALUES ('2005-01-01');
SELECT TO_DATE("df",'yyyy/mm/dd'), "df" FROM test;
SELECT * FROM test WHERE "df">='2005-01-01';
SELECT * FROM test WHERE TO_DATE("df",'yyyy/mm/dd')>='2005-01-01';
DROP TABLE test;
Instead the first select returns:
TO_DATE(DF,YYYY/MM/DD) DF
0005-01-01 00:00:00.0 2005-01-01 00:00:00.0
The second select returns correctly the row
DF
2005-01-01 00:00:00.0
However, the last select returns nothing.
This should be a bug, shouldn't it be?
With regards,
Christian-Manuel Butzke
Perpetuum Co. Ltd.

I am using Oracle Database 9. I encountered maybe a
bug of the to_date sql function.the bug is in your code, not in oracle!
CREATE TABLE test ("df" DATE);
INSERT INTO test VALUES ('2005-01-01');this is poor coding, you should use
insert into test values (to_date('2005-01-01', 'YYYY-MM-DD'));
SELECT TO_DATE("df",'yyyy/mm/dd'), "df" FROM test;this is also buggy code, you should use
select "dt" from test
to_date(date) is a source of errors
SELECT * FROM test WHERE "df">='2005-01-01';again, this is poor coding, you compare string with date. Prefer where "df" >= to_date('2005-01-01', 'YYYY-MM-DD')
SELECT * FROM test WHERE
TO_DATE("df",'yyyy/mm/dd')>='2005-01-01';same as above

TO_DATE with YYYY format mask behavior

I was selecting records from a table where a date in the table is prior to a given year:
SELECT * FROM the_table WHERE date_col <TO_DATE('2006','YYYY');
On January 31st, this worked fine.
On February 1st, I started seeing records from January 2006.
When I run the following in SQL*Plus, the result is 2/1/2006:
SELECT TO_DATE('2006','YYYY') FROM DUAL;
I have used this format before (but perhaps not in the exact situation) and I've never seen this issue before.
SQL*Plus is version 8.0.6.0.0. The result occurs on database versions 10.2.0.3.0 and 10.2.0.4.0.
I'm not understanding why the current date would have any effect on the SELECTed date.
Any insights would be appreciated.
Thanks!

Hi,
When you don't spedcify the month in TO_DATE, it defaults to the current month.
SELECT SYSDATE
, TO_DATE ('2006', 'YYYY')
FROM dual;just produced
02-Feb-2009 01-Feb-2006You have to give the month:
TO_DATE ('200601', 'YYYYMM')Edited by: Frank Kulash on Feb 2, 2009 3:21 PM
Or use TRUNC (..., 'YYYY'), as Walter showed you.

Rewrite condition WHERE TRUNC (data_operac) = to_date(:1, 'YYYY-MM-DD')

Hi,
I've got query with condition
WHERE TRUNC (data_operac) >= to_date(:1, 'YYYY-MM-DD') there is index b-tree on data_operac but cant be used (because of trunc) .
Is there any way I can rewrite that condition to make index usage possible ?
Regards.
Greg

Like this?
WHERE data_operac >= to_date(:1, 'YYYY-MM-DD')because following is always true
data_operac >= TRUNC (data_operac)

Why does to_date gives yyyy as 0006

Hi ,
this is from my nls_session paramete
        PARAMETER     VALUE
10     NLS_TIME_FORMAT     HH.MI.SSXFF AM
11     NLS_TIMESTAMP_FORMAT     DD-MON-RR HH.MI.SSXFF AMIf i execute the followings :
select TO_DATE(SYSDATE, 'DD-MM-YYYY') from dual
results --> 11/20/0006 the year is STRANGE
select TO_DATE(SYSDATE, 'DD-MM-YY') from dual
results --> 11/20/2006 th year is OKappreciate ur advise
tks & rdgs

Why are you using to_date on a date?
to_date accepts a character input value, when you pass a date it gets implicitly converted to a string using the nls_date_format value for the session and then back to a date again.
There is an example Re: TO_DAYS equivalant in Oracle

SetString(1,"TO_DATE('2004-01-17','YYYY-MM-DD')"); Will that work

Hi all,
Can you tell me whether I can have whole SQL sections in my setXXX methods when
using PreparedStatements?
setString(1,"TO_DATE('2004-01-17','YYYY-MM-DD')");I thought I had my program working with such a statement, but now when I try it
it doesn't work but rather give me the following error:
ORA-01858: a non-numeric character was found where a numeric was expected
SQL would be i.e. "INSERT INTO myTest (myDate) VALUES (?)"

Something peculiar I found was this:
In my pstmt's SQL is the following:
INSERT INTO myTable (myInt,myDate) VALUES (?,TO_DATE(?,'YYYY-MM-DD'))
pstmt.setString(1,'1'); //for the int using Oracle for converting
pstmt.setString(2,'2005-01-17'); // this what I would normally use
But I had run into problem where myDate was supposed to be NULL,
that's why I posted the initial question about putting SQL into the setXXX
statement. But, what I found was that I could instead also put in a setDate
in place of the setString:
pstmt.setDate(2,null); // This will work even though I have the TO_DATE
Why would that be? Will the pstmt simply ignore the TO_DATE statement?
dailySun

Info on TO_DATE function

After seeing many questions on TO_DATE function,I think it will be better to post
this useful information on to_date function.please correct me if i am wrong
anywhere in the post.
TO_DATE :
SYNTAX:TO_DATE(i/pstring[,i/pstringfmt[,nlsparam]])Note:Apart from third party tools which have their own default settings,the output of to_date is in the format specified by NLS_DATE_FORMAT parameter in NLS_DATABASE_PARAMETERS view.
Note: The format that we are specifying in to_date function is the format of the i/p string
and not the format of the o/p date.
Ex:
SQL> select to_date('12-JAN-2008','DD-MON-YYYY') from dual;
TO_DATE('
12-JAN-08
SQL> select to_date('12-01-2008','DD-MM-YYYY') from dual;
TO_DATE('
12-JAN-08
SQL> select to_date('12/01/2008','DD/MM/YYYY') from dual;
TO_DATE('
01-DEC-08Q) So, for to_date we have to give the format of i/p string. But in some cases, even if i give a format other than the format of i/p string, I am getting the o/p.
Ex1. SELECT to_date('01.JAN.2008','DD-MON-YYYY') from dual;
Ex2. SELECT to_date('01/JAN/2008','DD-MON-YYYY') from dual;
Ex3. SELECT to_date('01-JAN-2008','DD-MM-YYYY') from dual;
Ex4. SELECT to_date('01-JANUARY-2008','DD-MM-YYYY') from dual;A)The answer for 1 and 2 is, Oracle will not match separators(./-) in the string and format mask.
It only matches corresponding values. space can be a separators in the format mask.
Ex:select to_date('2008-01-01','YYYY MM DD') from dualIn case if the i/p string does not match with the format mask, Oracle substitutes the format mask element with its alternatives and even after this, if it cannot convert the i/p string to the given format mask, then it throws an error.
Alternate Format masks Table:
Format Mask Alternate Format Mask
Element       allowed in i/p String
MM       MON,MONTH
MON     MONTH
MONTH MON
YY       YYYY
RR        RRRR
RR         RRIn Ex3 and Ex4, we have MM in the format mask and MON (JAN), MONTH (JANUARY) in i/p string.
According to the above table, Oracle makes an implicit substitution of alternate format mask MON or MONTH
and hence it does not give an error. But this statement SELECT TO_DATE (’01-01-2008’,’DD-MON-YYYY’)
FROM DUAL will always error out because according to the above given table, if you have ‘MON’ in the format mask, then only MON (JAN) or MONTH (JANUARY) is allowed in the i/p string.
Q) Since format mask is optional, if i do not give any format mask, then How Oracle will convert the given string to a date?
A) If we do not specify any format mask, then Oracle assumes that the string is in default date format and tries to convert it into a date.If the i/p string is not in the default date format, then it will give an error.
Ex: Assume that the default date format is ‘DD-MON-RR’.
Now if you execute a statement like, SELECT to_date(’01-01-2009’) from dual, it will error out since it is not in the default format and also not convertable by implicit substitution according to the implicit substitution table.
Q)If i have time fields in the format mask and if i did not give them in the i/p string like select to_date('10-JAN-2008','DD-MON-YYYY HH24:MI:SS') from dual ,will it error out?
A)You can omit the time fields in the i/p string, beause if nothing is provided then Oracle will implicitly take time as 00:00:00 and hence it will not give an error.
Q)If i give some thing like select to_date('2008-05-01','DD-MM-YYYY') from dual, it errors out but if i give select to_date('2008-05','DD-MM-YYYY') from dual, then there is no problem. what is the reason for it?
A)On seeing the format mask DD-MM-YYYY, it takes first 2 digits (20) as DD ,the next 2 digits(08) as month, the next 2 digits for year(05).After coming this far, still there is some portion(01) of the string that is not matched and hence it throws an error and once we remove ‘01’ as given in the question, it works absolutely fine.
Edited by: Sreekanth Munagala on Feb 25, 2009 3:45 AM

I think what Boneist is saying, and I agree, is that the answer to the first Q is misleading.
Sreekanth Munagala wrote:
Q)Some people have a misconception that a statement like to_date('01-01-2008','DD-MM-YYYY') will always convert the string '01-01-2008' into a date with the given format 'DD-MM-YYYY'.
A)It might or might not .It all depends on value of NLS_DATE_FORMAT parameter in NLS_DATABASE_PARAMETERS view.Well,if the value of the parameter is 'DD-MM-YYYY'
then the answer is 'YES' else the answer is 'NO'.The Answer should simply be "It won't". with the reason being that "the DATE datatype does not have a display format, only an internal format which is consistent regardless of how you want to display it. The format specified in the TO_DATE function relates to the format of the input string; how the date returned from that function is _displayed_ is completely independant of, and unrelated to, the TO_DATE function."

TO_DATE function with JPA, Getting Unexpected Token error

I am constructing a search query like this from my JAVA code
SELECT * FROM EMAIL_PROXY_ERROR_LOG WHERE (to_date((REPLACE (DATETIME,'T',':')),'yyyy-mm-dd:hh24:mi:ss') BETWEEN to_date('2008-04-29:11:30:08','yyyy-mm-dd:hh24:mi:ss') AND to_date('2008-04-30:11:30:02','yyyy-mm-dd:hh24:mi:ss'))
I am using Toplink Essentials and I get the following error while running, what would be a possible solution
Exception Description: Syntax error parsing the query [select c FROM EmailProxyErrorLog c WHERE to_date((REPLACE (c.dateTime,'T',':')),'yyyy-mm-dd:hh24:mi:ss') BETWEEN to_date('2008-04-26:11:30:08','yyyy-mm-dd:hh24:mi:ss') AND to_date('2008-04-30:11:30:02','yyyy-mm-dd:hh24:mi:ss')], line 1, column 42: unexpected token [to_date].
Internal Exception: line 1:42: unexpected token: to_date
at oracle.toplink.essentials.exceptions.EJBQLException.unexpectedToken(EJBQLException.java:389)
at oracle.toplink.essentials.internal.parsing.ejbql.EJBQLParser.handleANTLRException(EJBQLParser.java:350)
at oracle.toplink.essentials.internal.parsing.ejbql.EJBQLParser.addError(EJBQLParser.java:278)
at oracle.toplink.essentials.internal.parsing.ejbql.EJBQLParser.reportError(EJBQLParser.java:378)
at oracle.toplink.essentials.internal.parsing.ejbql.antlr273.EJBQLParser.arithmeticPrimary(EJBQLParser.java:3617)
at oracle.toplink.essentials.internal.parsing.ejbql.antlr273.EJBQLParser.arithmeticFactor(EJBQLParser.java:3513)
at oracle.toplink.essentials.internal.parsing.ejbql.antlr273.EJBQLParser.arithmeticTerm(EJBQLParser.java:3407)
at oracle.toplink.essentials.internal.parsing.ejbql.antlr273.EJBQLParser.simpleArithmeticExpression(EJBQLParser.java:1021)
at oracle.toplink.essentials.internal.parsing.ejbql.antlr273.EJBQLParser.arithmeticExpression(EJBQLParser.java:2304)
at oracle.toplink.essentials.internal.parsing.ejbql.antlr273.EJBQLParser.simpleConditionalExpression(EJBQLParser.java:2282)
at oracle.toplink.essentials.internal.parsing.ejbql.antlr273.EJBQLParser.conditionalPrimary(EJBQLParser.java:2218)
at oracle.toplink.essentials.internal.parsing.ejbql.antlr273.EJBQLParser.conditionalFactor(EJBQLParser.java:2155)
at oracle.toplink.essentials.internal.parsing.ejbql.antlr273.EJBQLParser.conditionalTerm(EJBQLParser.java:2030)
at oracle.toplink.essentials.internal.parsing.ejbql.antlr273.EJBQLParser.conditionalExpression(EJBQLParser.java:1989)
at oracle.toplink.essentials.internal.parsing.ejbql.antlr273.EJBQLParser.whereClause(EJBQLParser.java:507)
at oracle.toplink.essentials.internal.parsing.ejbql.antlr273.EJBQLParser.selectStatement(EJBQLParser.java:184)
at oracle.toplink.essentials.internal.parsing.ejbql.antlr273.EJBQLParser.document(EJBQLParser.java:135)
at oracle.toplink.essentials.internal.parsing.ejbql.EJBQLParser.parse(EJBQLParser.java:166)
at oracle.toplink.essentials.internal.parsing.ejbql.EJBQLParser.buildParseTree(EJBQLParser.java:127)
at oracle.toplink.essentials.internal.ejb.cmp3.base.EJBQueryImpl.buildEJBQLDatabaseQuery(EJBQueryImpl.java:215)
at oracle.toplink.essentials.internal.ejb.cmp3.base.EJBQueryImpl.buildEJBQLDatabaseQuery(EJBQueryImpl.java:189)
at oracle.toplink.essentials.internal.ejb.cmp3.base.EJBQueryImpl.buildEJBQLDatabaseQuery(EJBQueryImpl.java:153)
at oracle.toplink.essentials.internal.ejb.cmp3.base.EJBQueryImpl.<init>(EJBQueryImpl.java:114)
at oracle.toplink.essentials.internal.ejb.cmp3.base.EJBQueryImpl.<init>(EJBQueryImpl.java:99)
at oracle.toplink.essentials.internal.ejb.cmp3.EJBQueryImpl.<init>(EJBQueryImpl.java:86)
at oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerImpl.createQuery(EntityManagerImpl.java:204)
Caused by: line 1:42: unexpected token: to_date
at oracle.toplink.essentials.internal.parsing.ejbql.antlr273.EJBQLParser.arithmeticPrimary(EJBQLParser.java:3611)

Hello,
The JPQL dies not define a to_date function, which is why it will throw an exception when parsing the query string. You will need to use a native query for this if you need to convert database fields to dates for comparison.
Best Regards,
Chris

Importing timestamp columns appears to use to_date instead of to_timestamp

I'm trying to import data (using the latest version 1.5.4 with Patch 2 applied) to an Oracle 10g database that contains timestamp columns. The input data has times with fractional (millisecond) values The data was exported using SQL Developer from a Sybase database and the timestamp format in the Excel (xls) file is YYYY-MM-DD HH24:MI:SS.FF3. When I specify this format for the TIMESTAMP columns on the import screens, the importer generates an insert statement like this:
INSERT INTO A (TMS) VALUES (to_date('2008-12-049 12:12:39.967', 'YYYY-MM-DD HH24:MI:SS.FF3'));
This command fails to execute with this error:
Error report:
SQL Error: ORA-01821: date format not recognized
01821. 00000 - "date format not recognized"
*Cause:
*Action:
I found that if to_timestamp is used instead of to_date, there is no issue inserting the row with the correct time precision. The question I have is why isn't SQL Developer using to_timestamp for importing a TIMESTAMP column, and should it?
Any advise woudl be appreciated.
Thanks

In 1.5.4 I see a bug where the "Format" field doesn't show up in the page in the import wizard, preventing the user from entering a mask when the column type is TIMESTAMP. This has been fixed in the code line under development and should be available when 2.1 gets released.
To give you a bit more detail on the confusing DATE/TIMESTAMP behaviour...
SQL Developer misrepresenting date as timestamp and vice versa stems from the behaviour of the Oracle JDBC driver. Following are the details I obtained from the JDBC team when I raised a bug("WRONG VALUE RETURNED FOR GETCOLUMNTYPE FOR DATE COLUMN ") on them:-
oracle.jdbc.mapDateToTimestamp is by default set
to true to indicate reporting DATE column as TIMESTAMP type. To turn off, pass
-Doracle.jdbc.mapDateToTimestamp=false" at the command line.
To effect this option in SQL Developer, you can add an AddVMOption -Doracle.jdbc.mapDateToTimestamp=false
A bit more history on the option:
8i and older Oracle databases did not support SQL TIMESTAMP, however Oracle
DATE contains a time component, which is an extension to the SQL standard. In
order to correctly handle the time component of Oracle DATE the 8i and
earlier drivers mapped Oracle DATE to java.sql.Timestamp. This preserved the
time component.
Oracle database 9.0.1 included support for SQL TIMESTAMP. In the process of
implementing support for SQL TIMESTAMP we changed the 9i JDBC driver to map
Oracle DATE to java.sql.Date. This was an incorrect decision since it
truncates the time component of Oracle DATE. There was also a backwards
compatibility problem trying to write java.sql.Timestamps to 8i databases.
These are separate problems but we "fixed" both under the control of a single
flag, V8Compatible. This flag was introduced in a 9.2 patch set.
By default the flag is false. When it is set to false the driver maps Oracle
DATE to java.sql.Date, losing the time component and it writes
java.sql.Timestamps to the database as SQL TIMESTAMPS. When the flag is set
to true the driver maps Oracle DATE to java.sql.Timestamp and writes
java.sql.Timestamps to the database as Oracle DATEs.
In 11.1 the V8Compatible flag was deprecated because it controlled Database
8i compatibility which is no longer supported. The additional behavior it
controlled, how SQL DATEs are handled, is controlled by a new flag,
mapDateToTimestamp. In 11.1 setting V8Compatible will just set
mapDateToTimestamp. This new flag only controls how SQL DATEs are
represented, nothing more. This flag will be supported for the foreseeable
future.
Finally, the default value for V8Compatible is false in 9i and 10g. This
means that by default the drivers incorrectly map SQL DATEs to java.sql.Date.
In 11.1 the default value of mapDateToTimestamp is true which means that by
default the drivers will correctly map SQL DATEs to java.sql.Timestamp
retaining the time information. Any customer that is currently setting
V8Compatible = true in order to get the DATE to Timestamp mapping will get
that behavior by default in 11.1. Any customer that wants the incorrect but
10g compatible DATE to java.sql.Date mapping can get that by setting
mapDateToTimestamp = false in 11.1.
About the only way to see the difference between mapDateToTimestamp settings
is to call getObject on a DATE column. If mapDateToTimestamp is true, the
default setting, the result will be a java.sql.Timestamp. If
mapDateToTimestamp is false, then getObject on a DATE column will return a
java.sql.Date.
HTH
Edited by: vasan_kps on Jun 12, 2009 2:01 PM

To_date a date-like string

Hi,
I have a string like this:
2008-03-19T01:00:02Z
How can I make this string to date (ignore T and Z)?
Thanks in advance.

SQL> SELECT TO_DATE('2008-03-19T01:00:02Z', 'YYYY-MM-DD"T"HH:MI:SS"Z"') DT
2 FROM dual;
DT
2008-03-19 01:00:02Regards,
Dima

Query about TO_DATE,thanks

there is a sql.
select to_date('2008年10月15日',fmt,nlsparm) from dual
fmt= ?????
nlsparm=CHINESE.ZHS16GBK?????
regards,
lao

Aketi Jyuuzou wrote:
dear BluShadow
Moon is correct.
Moon means month in Japanese.
But Sun is incorrect.
日 means "Sunday" and "Day"
in this case, that means day.Ok, I wasn't meaning necessarily the literal translation, but what the kanji represents.
The English word "month" is derived from "moon" anyway because it is based around the phases of the moon, so English and Japanese agree in that respect.
I we look at the kanji for "bright" (明) it is made up of the individual kanji for the sun and the moon.
And whilst "sun" by itself doesn't translate to 日, we can see that "sunday" translates to 日曜日. Yes, yes, I know that there isn't literal translations between english and kanji, but it's fair to say that 日 is a representation of the sun and of day and the counterpart moon kanji is based on the sun/day kanji because moonlight is reflected sunlight.
moonlight translates to 月光
sunlight translates to日光
(where 光 is the kanji for light as it represents a person carrying a torch/flame)
;)

Case sensitive field in to_date function

update "Ab_Order" set "OrderDate" = to_date("Order Date String", 'yyyy/mm/dd)
Here the OrderDate column is of type Date
"Order Date String" is varchar2. Iam trying to copy the data from "Order Date String" which contains data in this format '2011/04/24' to OrderDate column to perform some date functions
when I try to run this query it gives a error: ORA-01830: date format picture ends before converting entire input string
So I tried to run this query by creating a test table wit 2 columns : update testtable set column1 = to_date(field1, 'yyyy/mm/dd')
where column1 is date field and field1 is varchar2 and this worked.
So Iam assuming this is the problem with case sensitive fieldnames . As far as i know we should include case sensitive fields in double quotes. Is there anything else to do wit the to_Date function. Can anyone please let me know how to do that.

Hi,
Welcome the the forum!
882431 wrote:
update "Ab_Order" set "OrderDate" = to_date("Order Date String", 'yyyy/mm/dd)It looks like you're missing a single-quote right before the last ')'.
Here the OrderDate column is of type Date
"Order Date String" is varchar2. Iam trying to copy the data from "Order Date String" which contains data in this format '2011/04/24' to OrderDate column to perform some date functions
when I try to run this query it gives a error: ORA-01830: date format picture ends before converting entire input stringThat error occurs when when you have characters in the 1st argument that do not correspond to anything in the 2nd argument. For example:
TO_DATE ( '30-Aug-2011 12:00'
, 'dd-Mon-yyyy'
)In this example, TO_DATE doesn;t know what to do with the ' 12:00' at the end of the 1st argument. According to the 2nd arguemnt, there's only supposed to be 11 characters in the string. So it raises the ORA-01830 error.
So I tried to run this query by creating a test table wit 2 columns : update testtable set column1 = to_date(field1, 'yyyy/mm/dd')
where column1 is date field and field1 is varchar2 and this worked.
So Iam assuming this is the problem with case sensitive fieldnames . As far as i know we should include case sensitive fields in double quotes. Is there anything else to do wit the to_Date function. Can anyone please let me know how to do that.Case sensitive column names are a bad idea because they cause so amny problems, but I don't think this is one of those problems. It's more likely that you need to use SUBSTR (or some other string manipulation function) on "Order Date String" before using it in TO_DATE.
Whenever you have a problem, please post a little sample data (CREATE TABLE and INSERT statements, relevant columns only) from all tables, so people can re-create the problem and test their ideas.
Also post the results you want from that data, and an explanation of how you get those results from that data, with specific examples.
Always say which version of Oracle you're using.

Converting Year in YYYY format for return in select list

Using Apex 4.1.1 on Linux (Apex Listener on glassfish)
I have a table with week ending dates and use this table for as my LOV.
The select list comes up like 12-SEP-12 when I check the value attribute in Firebug. Problem is that this comes up as year 0012 instead of 2012 when I try to use it in my PL SQL code to save it to a table.
Is there a way I can get the return value for the year in YYYY format for return value in select list? Have tried to_date(dt, 'DD-MON-YYYY') with no luck.
Cheers.

All APEX session state values are held as VARCHAR2s. Explicit conversion to and from DATE values using specified formats is recommended. Convert to VARCHAR2 in the LOV query:
select to_char(week_ending, 'DD-MON-YYYY') l, to_char(week_ending, 'YYYY-MM-DD') v from ...and to DATE in the PL/SQL process code:
...to_date(:p1_week_ending, 'YYYY-MM-DD')...I'm trying to standardise on using ISO 8601 representations for non-displayed date values. These are unambiguous, sort properly using character semantics, and are compatible with other systems and technologies.

TO_DATE misbehaving in PL/SQL function

Hello,
Probably just missing something obvious, but does anyone have any ideas why the TO_DATE below doesn't work?
create or replace function columnsforest(target_table_name in varchar2)
return varchar2
as columns_string varchar2(32000);
cursor getColumnNames (target_table_name varchar2) is
select column_name, data_type from user_tab_cols
where table_name = target_table_name;
begin
for col in getColumnNames(target_table_name)
loop
    if (col.column_name != 'STUDY_ID')
    then
      if col.data_type = 'DATE'
      then columns_string := columns_string || 'TO_DATE('||col.column_name||',''YYYY-MM-DD HH24:MI:SS'') as D'||col.column_name||', ';
      else columns_string := columns_string || col.column_name || ', ';
      end if;
    end if;
end loop;
columns_string := rtrim(columns_string,', ');
return columns_string;
end;Say col.column_name (a string) was DATE_CHANGED, I would expect the line of code above to produce the following:
TO_DATE(DATE_CHANGED,'YYYY-MM-DD HH24:MI:SS') as DDATE_CHANGEDBut I always end up with my default date presentation (06-JUN-06). What am I doing wrong? I know this line is being executed because the D always appears before the column name...
Thanks for your help,
Gary

Hello
It's down to your NLS_DATE_FORMAT:
SQL> select sysdate from dual;
06-JUN-06
SQL> select to_date('2006-06-06','YYYY-MM-DD') from dual;
06-JUN-06
SQL> select to_date('2006-06-06 14:43:00','YYYY-MM-DD hh24:mi:ss') from dual;
06-JUN-06
SQL> alter session set nls_date_format='DD-MON-YYYY HH24:MI:SS'
2 /
Session altered.
SQL> select to_date('2006-06-06 14:43:00','YYYY-MM-DD hh24:mi:ss') from dual;
06-JUN-2006 14:43:00
SQL> alter session set nls_date_format='YYYY-MM-DD HH24:MI:SS'
2 /
Session altered.
SQL> select to_date('2006-06-06 14:43:00','YYYY-MM-DD hh24:mi:ss') from dual;
2006-06-06 14:43:00
SQL> select sysdate from dual;
2006-06-06 14:44:37HTH
David

OWB 10gR1 Convert Date format (mm-dd-yyyy) to (yyyy-mm-dd)

Hi All,
In OWB 10gR1, I have flatfiles with Date fields having the format (mm-dd-yyyy). I want to load this data into the Staging table in (yyyy-mm-dd) format. How could I do this conversion in my staging mapping ?
Using external tables is not an option.
An detailed answer will be extremely helpful.
Thanks community.

Wich is this field's datatype in database? Is it date or char? If you are going to store it as a date datatype, you don't have to worry about the date format.
Have you tried using the Expression Operator to perform the date string conversion in your mapping? Sorry about this lame drawing, but I think it will help you understand:
source_table ------------ALL_COLUMNS_EXCEPT_DATE_DATATYPE-------TARGET_TABLE
             |                                                 |
             +-------EXPR{TO_DATE(DATE_FIELD, 'DATE_FORMAT')}--+In this example, you'll use an expression operator to convert the date string in the format you want. Map other attributes directly to your target table (or other transformations you need to perform).
This is the generated script of a dummy plan I've built here:
OPTIONS ( ERRORS=50, BINDSIZE=50000, ROWS=200, READSIZE=65536)
LOAD DATA
CHARACTERSET WE8MSWIN1252
INFILE '{{LOC_FILE.RootPath}}load.csv'
INTO TABLE "LOAD_TARGET"
APPEND
REENABLE DISABLED_CONSTRAINTS
FIELDS
    TERMINATED BY ';'
    OPTIONALLY ENCLOSED BY '"'
"COD" POSITION (1) INTEGER EXTERNAL ,
"NOME" CHAR ,
"DATA" CHAR "to_date( :\"DATA\" , 'yyyy-mm-dd')"
)Regards,
Marcos

To_date('2008','yyyy') = April 1, 2008

Similar Messages

Maybe you are looking for