Re: timestamp <-> ctime conversion question...

Поиск
Список
Период
Сортировка
От Karsten Hilbert
Тема Re: timestamp <-> ctime conversion question...
Дата
Msg-id 20051213192119.GM5531@merkur.hilbert.loc
обсуждение исходный текст
Ответ на Re: timestamp <-> ctime conversion question...  (Michael Fuhr <mike@fuhr.org>)
Ответы Re: timestamp <-> ctime conversion question...  (Michael Fuhr <mike@fuhr.org>)
Re: timestamp <-> ctime conversion question...  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-general
On Tue, Dec 13, 2005 at 10:28:42AM -0700, Michael Fuhr wrote:

> According to the Date/Time Types documentation,
>
>     All timezone-aware dates and times are stored internally in UTC.
>     They are converted to local time in the zone specified by the
>     timezone configuration parameter before being displayed to the
>     client.
>
> As far as I know there isn't a way to defeat this.  However, the
> developers' TODO file does have the following item:
>
>     Allow TIMESTAMP WITH TIME ZONE to store the original timezone
>     information, either zone name or offset from UTC
>
> Presumably this would allow timestamps to be displayed with a
> timezone other than the current setting.
*Display* of timestamptz values at arbitrary time zones is
already possible using the "at time zone" syntax. Retrieving
the "original" (as in "as inserted"), however, isn't
possible to date. It would certainly be very useful. In
GNUmed we are currently solving this by explicitely storing
the original timestamp via a trigger on insert. I wonder
whether a good intermediate solution would be to have an
"officially supported" (whatever that means) composite
type ?

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

В списке pgsql-general по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Performance large tables.
Следующее
От: Michael Fuhr
Дата:
Сообщение: Re: timestamp <-> ctime conversion question...