Re: Date trunc in UTC - Mailing list pgsql-sql

From Tom Lane
Subject Re: Date trunc in UTC
Date
Msg-id 11965.1037892419@sss.pgh.pa.us
Whole thread Raw
In response to Re: Date trunc in UTC  (Richard Huxton <dev@archonet.com>)
List pgsql-sql
Richard Huxton <dev@archonet.com> writes:
> Hmm - good point. You can revert to the client default but not to the
> previous value. I don't know of any way to read these SET values
> either - a quick poke through pg_proc didn't show anything likely.

In 7.3 you can use current_setting() and set_config() to access SHOW/SET
functionality.  However, I agree with your suggestion of AT TIME ZONE
to rotate a timestamp into a target timezone, rather than mucking with
the TimeZone setting.


BTW, Thomas: is AT TIME ZONE supposed to accept
timestamp-without-timezone input?  If so, what's it supposed to do with
it?  The current behavior seems unintuitive to say the least:

regression=# select now();             now
-------------------------------2002-11-21 10:19:14.591001-05
(1 row)

regression=# select now() at time zone 'UTC';         timezone
----------------------------2002-11-21 15:19:18.588279
(1 row)

regression=# select localtimestamp;        timestamp
----------------------------2002-11-21 10:19:22.629865
(1 row)

regression=# select localtimestamp at time zone 'UTC';          timezone
-------------------------------2002-11-21 05:19:26.178861-05
(1 row)

It seems to me that the last case should give either an error or
2002-11-21 15:19:26.178861 (ie, assume that the timestamp without time
zone is in my TimeZone zone).  In any case, surely the result should
be of type timestamp WITHOUT time zone?
        regards, tom lane


pgsql-sql by date:

Previous
From: "Henshall, Stuart - Design & Print"
Date:
Subject: Re: help optimise this ?
Next
From: Tom Lane
Date:
Subject: Re: help optimise this ?