From: | Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | jason(dot)servetar(at)ccgenesis(dot)com, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: to_date/to timestamp going to BC |
Date: | 2001-10-04 08:41:49 |
Message-ID: | 20011004104149.B9858@zf.jcu.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On Wed, Oct 03, 2001 at 05:14:02PM -0400, Tom Lane wrote:
> jason(dot)servetar(at)ccgenesis(dot)com writes:
> > Can someone tell me if this is a bug with the date functions or am I using
> > them incorrectly?
>
> I get the right thing when I use the right format:
>
> regression=# select dt, to_timestamp(dt, 'FMMonth dd, yyyy') from test_date;
> dt | to_timestamp
> ----------------+------------------------
> March 11, 1997 | 1997-03-11 00:00:00-05
> (1 row)
>
> However, I'd agree that this shows a lack of robustness in to_timestamp;
> it's not objecting to data that doesn't match the format.
The manual is transparent about this. I can add feauture that will
check everythig, but users who knows read manual and use already
debugged queries will spend CPU on non-wanted code.
Hmm.. I look at Oracle, and it allows parse queries like:
SVRMGR> select to_date('March 11, 1997', 'Month dd, yyyy') from dual;
TO_DATE('
---------
11-MAR-97
1 row selected.
.. well, I add it to my TODO for 7.3 (I plan rewrite several things
in to_* functions).
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
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Sawtell | 2001-10-04 12:46:01 | Re: |
Previous Message | Advid@newgen | 2001-10-04 03:47:40 | maximum parameters limit to function & manipulating array in plpgsql |