Re: Date trunc in UTC

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Date trunc in UTC
Дата
Msg-id 11965.1037892419@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Date trunc in UTC  (Richard Huxton <dev@archonet.com>)
Список 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 по дате отправления:

Предыдущее
От: "Henshall, Stuart - Design & Print"
Дата:
Сообщение: Re: help optimise this ?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: help optimise this ?