Is there anyone who knows the answer as to why now() is delivering a different time answer than Windows? -----Original Message----- From: Tom Lane [mailto:tgl@xxxxxxxxxxxxx] Sent: Monday, September 12, 2005 6:42 PM To: Lane Van Ingen Cc: pgsql-admin@xxxxxxxxxxxxxx Subject: Re: Server Time Setting "Lane Van Ingen" <lvaningen@xxxxxxxxx> writes: >> I am baffled as to why some of the PostgreSQL functions (like now() ) are >> returning a time which is exactly an hour later than the server's actual >> system time. > I'd say you've got TimeZone set to something different than you think > you do. > regards, tom lane Before I asked this question yesterday, I had already checked SHOW ALL and found only two PostgreSQL config parameters that seemed to apply, and they appeared to be set properly: australian_timezones = no TimeZone = US/Eastern We are running 8.0.1, Windows 2003. Since last message, checked 3 other servers, and found that I have the same problem on two out of three: Server #1: select now() agreed with Windows time on this one Server #2: select now() was exactly one hour greater than Windows time where config parms were set the same as previous paragraph Server #3: select now() was exactly one hour greater than Windows time, but config parm was set wrong: TimeZone = Europe/Dublin (don't know how that happened; makes you wonder if TimeZone has anything to do with this at all!) Windows 2003 time was set correctly in all four cases. Summary: - one server displays time correctly - two servers APPEAR to be set correctly, but time displayed from now() as one hour greater than Windows time - one server is set incorrectly, but TimeZone did not appear to have any effect on the time being displayed; now() just displayed time as one hour greater than Windows time Being as one server is 'doing it right', there must be some difference, but so far I have not found what is different. Windows appeared to be correct in all cases, but PostgreSQL did not. ---------------------------(end of broadcast)--------------------------- ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
