On Mon, 20 Nov 2006, Tom Lane wrote:

My database in configured to timezone Europe/Helsinki aka +0200. I knew that
the floating point stamps are not fully accurate, but I showed the result with
that setting too, just to prove that the internal storing/handling format did
not matter in this bug.

Where can I find out what function is used for my timezone ? And even if there
would be different timezone calculation formulas for different timezones I do
not believe that the date of the timestamp should be a parameter that affects
the result.

Further notice that the insert statements included a fully qualified timestamp
including the timezone so that the database local timezone won't affect the
inserted value. On the other hand I do think that the values printed by select
can be affected by the database timezone.

I would very much like someone to try the small insert/select statements in my
bug report and to verify if the bug is in my setup or if it is a real bug.

My current quess is that when doing the math of converting from gregorian
calendar system to julian (or vise versa) postgresql forgets to clear the time
component from the timestamp before adjusting the date, resulting in the time
shifted with some strange constant.

-Mikko

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On Tue, 21 Nov 2006, Heikki Linnakangas wrote:


Ok. Thank you for clearing this up.

I'm sorry to have bothered you with the issue. I'll go back to wondering why
the java jdbc postgresql driver is 3x slower when it sees the odd timezone in
the response.

-Mikko

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly