The biggest point that I see is that it would be nice to have some kind
of function that works with UTC values, regarding of which timezone the
user has set. Let's say, something like
SELECT UTC_DATE_TRUNC ('month', NOW ());
utc_date_trunc
------------------------ 2002-11-01 01:00:00+01
because if you work with international applications, the beggining of
the month in Spain should be the same as in Australia. But everyone will
see it in its own timezone.
I think that it would be also interesting to have the UTCeed versions of
EXTRACT and AGE.
Tom Lane wrote:
> 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
>
>
