Magnus Hagander <magnus@hagander.net> writes:
> On Thu, Aug 23, 2012 at 3:42 PM, Tom Lane <tgl@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
