Re: BUG #7886: date_trunc(date) returning timestamptz instead of timestamp

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

In response to

Browse pgsql-bugs by date

  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