On Fri, Mar 11, 2005 at 03:25:28PM +0100, Egy?d Csaba wrote:
> Hi All,
> I'd like to ask your opininon about how to handle DST on an 7/24 system.
> Where should it be handled: on the server side or on the client side? And
> how could I (at all could I???) make it transparent?
As others have menti
On Sat, Mar 12, 2005 at 05:44:52PM +0100, Karsten Hilbert wrote:
> On Fri, Mar 11, 2005 at 01:43:21PM -0500, Randall Nortman wrote:
>
> > As others have mentioned, store timestamps on the server in UTC,
>
> 1) As long as I store them as I should
> not need to care what they
l times to UTC before
inserting them. This should avoid all such problems in the future.
PostgreSQL version (client and server) is 7.4.5, on i686 Debian sarge.
The client app is in python 2.3.4 using psycopg.
Thanks,
Randall Nortman
---(end of broadcast)---
TIP 8: explain analyze is your friend
On Sun, Oct 31, 2004 at 11:52:03AM -0500, Tom Lane wrote:
> Randall Nortman <[EMAIL PROTECTED]> writes:
> > My suspicion is that Postgres calculates the local offset from UTC
> > only once per session, during session initialization.
>
> This is demonstrably not so. We
On Sun, Oct 31, 2004 at 12:47:31PM -0500, Tom Lane wrote:
> Randall Nortman <[EMAIL PROTECTED]> writes:
> > I can't reproduce the error without messing up my clock, but from my
> > logs, here's the text of the SQL sent to the server:
>
> > insert
On Sun, Oct 31, 2004 at 02:44:51PM -0500, Tom Lane wrote:
> Randall Nortman <[EMAIL PROTECTED]> writes:
> > Ah, I see now. PostgreSQL is behaving a bit differently than I
> > expected. The timestamp string above is ambiguous in the timezone
> > US/Eastern -- it
