[BUGS] BUG #6001: date_trunc is not timezone aware
The following bug has been logged online:
Bug reference: 6001
Logged by: Marek Nos
Email address: marek@centrum.cz
PostgreSQL version: 9.0
Operating system: Windows 7
Description:date_trunc is not timezone aware
Details:
and other like extract() as well
SELECT date_trunc('day', '2011-05-02 02:00:00+05'::timestamptz)
I would expect result as
'2011-05-02 00:00:00+05'
but
'2011-05-01 00:00:00+02' is given (pre conversion to server timezone is done
first)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6001: date_trunc is not timezone aware
On Sun, May 01, 2011 at 06:48:57PM +, Marek Nos wrote:
>
> The following bug has been logged online:
>
> Bug reference: 6001
> Logged by: Marek Nos
> Email address: marek@centrum.cz
> PostgreSQL version: 9.0
> Operating system: Windows 7
> Description:date_trunc is not timezone aware
> Details:
>
> and other like extract() as well
>
> SELECT date_trunc('day', '2011-05-02 02:00:00+05'::timestamptz)
>
> I would expect result as
> '2011-05-02 00:00:00+05'
> but
> '2011-05-01 00:00:00+02' is given (pre conversion to server timezone is done
> first)
because you didn't specify which timezone you *want*.
when you're connecting to server, and not providing your own time zone,
it is assumed that you're using the same time zone as server.
and all timestamptz, in all time zones, are converted to your time zone:
$ show timezone;
TimeZone
--
Poland
(1 row)
$ select now();
now
--
2011-05-02 12:43:56.56492+02
(1 row)
$ SELECT '2011-05-02 02:00:00+05'::timestamptz;
timestamptz
2011-05-01 23:00:00+02
(1 row)
To make the calculations work in different time zone, simply set it:
$ set timezone = '+05';
SET
$ select now();
now
---
2011-05-02 15:44:38.044978+05
(1 row)
$ SELECT '2011-05-02 02:00:00+05'::timestamptz;
timestamptz
2011-05-02 02:00:00+05
(1 row)
$ SELECT date_trunc('day', '2011-05-02 02:00:00+05'::timestamptz);
date_trunc
2011-05-02 00:00:00+05
(1 row)
depesz
--
The best thing about modern society is how easy it is to avoid contact with it.
http://depesz.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] documentation bug - behave of NEW a OLD in plpgsql's triggers
Hello one czech user reported a bug in documentation - http://www.postgresql.org/docs/8.4/static/plpgsql-trigger.html NEW Data type RECORD; variable holding the new database row for INSERT/UPDATE operations in row-level triggers. This variable is NULL in statement-level triggers and for DELETE operations. OLD Data type RECORD; variable holding the old database row for UPDATE/DELETE operations in row-level triggers. This variable is NULL in statement-level triggers and for INSERT operations. It isn't correct. NEW is not declared in DELETE trigger, OLD isn't declared in INSERT Regards Pavel Stehule -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6000: error de instalacion
2011/4/29 Philippe Reyes Courrau : > > The following bug has been logged online: > > Bug reference: 6000 > Logged by: Philippe Reyes Courrau > Email address: philippecour...@gmail.com > PostgreSQL version: postgresql-9.0. > Operating system: windows xp sp3 > Description: error de instalacion > Details: > > al ejecutar el instalador postgresql-9.0.4-1-windows, se produce un error > que dice: Unable to write inside TEMP enviroment variable path. ¿Ha revisado el contenido de la variable TEMP? Es válido? ¿Hay espacio disponible? -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5946: Long exclusive lock taken by vacuum (not full)
Greg Stark writes: > So is it ok for inserting one row to cause my table to grow by 90GB? > Or should there be some maximum size increment at which it stops > growing? What should that maximum be? What if I'm on a big raid system > where that size doesn't even add a block to every stripe element? I'd think that capping the idea to the segment size makes sense. Also, what about having a background process (bgwriter or autovacuum come to mind) doing the work, rather than the backend that happens to be inserting the row? It could send a message, and continue creating a newer 8kb block if the background process has not yet extended the storage. Also, to be safe I guess we could arrange to have the new segment be created way before reaching the very end of the relation (so that adding 8kb does not need to create a new segment, so as to avoid a race condition with the background process doing so itself). Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6002: French character show garbled
The following bug has been logged online: Bug reference: 6002 Logged by: Savita Email address: savita.ha...@gmail.com PostgreSQL version: 8.3.5 Operating system: AIX Description:French character show garbled Details: Hi We are facing a problem while inserting a Latin character (é) into Postgresql. We are using postgresql-8.3-604.jdbc3.jar to connect to the PSQL and trying to insert the following statement: "Vérification" through JDBC. Once inserted we went back to PSQL and ran the select query and the result is different: Vérification. Here the character é is being replaced by é. Could any one please help us in resolving this problem as we are stuck with this? Note: We have even tried this on Database with encoding SQL_ASCII and UTF8 as well. Thanks Savita -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
