Magnus Hagander <mag...@hagander.net> writes: > On Thu, Aug 23, 2012 at 3:42 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> to_timestamp is intentionally pretty loose. Personally, if I wanted >> sanity checking on a date string in any common format, I would just >> cast the string to timestamp(tz), and *not* use to_timestamp.
> Shouldn't we put at least a note, and IMO even a *warning* in the docs > saying that it is like this? (or am I missing one we have) It's not > really consistent with how most of postgres works :) I have no objection to a note and even a couple of examples, but try to keep down the dudgeon --- the reason it's like this is that people have found it useful for the conversion to be forgiving about field ranges. An example is that you can compute "next week" by adding 7 to the day field, without worrying about whether you need to wrap that at 28, 29, 30, or 31 days. This behavior corresponds directly to Unix mktime(3), which is required by POSIX spec to be lax about field ranges. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers