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 <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
