Skip site navigation (1) Skip section navigation (2)

Re: to_date problem

From: Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
To: leif(at)danmos(dot)dk
Cc: pgsql-interfaces(at)postgresql(dot)org
Subject: Re: to_date problem
Date: 2001-03-15 10:27:48
Message-ID: 20010315112748.B28603@ara.zf.jcu.cz (view raw or flat)
Thread:
Lists: pgsql-interfaces
On Thu, Mar 15, 2001 at 08:37:26AM +0100, leif(at)danmos(dot)dk wrote:
> 
>    Hello,
> 
>   I have just observed the following problem:
> 
> -------------------------------------------------------------------
> testdb=# select to_date('2001-3-5 10:00', 'YYYY-MM-DD HH24:MI') from dual;
>   to_date   
> ------------
>  2001-03-10
> (1 row)
> 

 Hmm .. because 'MM'and 'DD' expect two digits, more correct is en example 
(without Oracle's fundamental "from dual" :-)

test=# select to_date('2001-03-05 10:00', 'YYYY-MM-DD HH24:MI');
  to_date
------------
 2001-03-05
(1 row)

or you can use 'FM' - "fill mode" switch:

test=# select to_date('2001-3-5 10:00', 'YYYY-FMMM-FMDD HH24:MI');
  to_date
------------
 2001-03-05
(1 row)


 The common rule: data that you want parse in to_date() must be formatted
like output from to_char() with same format mask. The to_char() never output
'2001-3-5 10:00' for 'YYYY-MM-DD HH24:MI'.


 Hmm, now I see Oracle and it allows correct parse this dirty query...

 SVRMGR> select to_date('2001-3-5 10:00', 'YYYY-FMMM-FMDD HH24:MI') from
dual;
TO_DATE('
---------
05-MAR-01
1 row selected.

 ..but nothing say Oracle's documentation about this (IMHO). Well I add it
to my TODO for 7.2, but it's prop for users those not reading docs...  

			Karel

-- 
 Karel Zak  <zakkr(at)zf(dot)jcu(dot)cz>
 http://home.zf.jcu.cz/~zakkr/
 
 C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz

In response to

Responses

pgsql-interfaces by date

Next:From: J. T. VermeulenDate: 2001-03-15 12:07:13
Subject: Re: Big trouble with libpq++
Previous:From: leifDate: 2001-03-15 07:37:26
Subject: to_date problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group