From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | nick(dot)baxter(at)gmail(dot)com, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #7886: date_trunc(date) returning timestamptz instead of timestamp |
Date: | 2013-02-15 22:14:53 |
Message-ID: | 18305.1360966493@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> On Fri, Feb 15, 2013 at 09:27:40PM +0000, nick(dot)baxter(at)gmail(dot)com wrote:
>> 9.9.2. indicates that date_trunc can be called with a date value (which will
>> be cast to a timestamp). And regardless of the input, that the result will
>> be of type timestamp. When I call it with a date, I get a timestamp with
>> time zone instead, as indicated by the psql output.
> That documentation often uses timestamp when it means timestamp with
> time zone. Not sure why that is.
Well, what the subsection about date_trunc says is "source is a value
expression of type timestamp or interval". Up at the very top of the
page, it says
All the functions and operators described below that take time
or timestamp inputs actually come in two variants: one that
takes time with time zone or timestamp with time zone, and one
that takes time without time zone or timestamp without time
zone. For brevity, these variants are not shown separately.
So omitting mention of date_trunc(timestamptz) is not inconsistent.
If we wanted to fix that the page would get quite a bit longer, but
perhaps not much more illuminating.
It strikes me that the problem is in the parenthetical remark in 9.9.2:
"(Values of type date and time are cast automatically to timestamp or
interval, respectively.)". Since there are both timestamp and
timestamptz alternatives available, the parser will actually prefer to
cast a date input to timestamptz, that being the preferred type in this
category. Maybe we should say "timestamp with time zone" there, though
I can see that confusing people in a different way.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Thomas | 2013-02-15 23:07:20 | Re: BUG #7885: postmaster panic on startup does not release shared memory |
Previous Message | Dave Rolsky | 2013-02-15 22:06:12 | Re: BUG #7873: pg_restore --clean tries to drop tables that don't exist |