From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Campano, Troy" <Troy(dot)Campano(at)LibertyMutual(dot)com> |
Cc: | "Postgres general mailing list" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: timestamp/date comparison |
Date: | 2004-02-15 17:05:08 |
Message-ID: | 8784.1076864708@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Campano, Troy" <Troy(dot)Campano(at)LibertyMutual(dot)com> writes:
> anna> SELECT request_date,TO_DATE(request_date,'YYYY-MM-DD HH24:MM:SS')
The correct way to write the format string would have been
SELECT request_date,TO_DATE(request_date,'YYYY-MM-DD HH24:MI:SS')
(minutes are MI not MM). It was evidently taking the minute number as
month number, and not noticing that the field was out of range :-(.
People have complained before that to_date() and related functions don't
detect all the error cases one would reasonably expect them to complain
about ...
However, this all seems like the hard way to solve your problem.
Why don't you just cast the timestamp value to date type, ie
"CAST(request_date AS date)", or just "request_date::date" if you don't
mind using a Postgres-specific syntax. The date_trunc() function also
is worth knowing about.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-02-15 17:07:28 | Re: Using NOTIFY... Slow Client Querys |
Previous Message | Tom Lane | 2004-02-15 16:55:00 | Re: PostgreSQL in a shared-disk enviroment |