Skip site navigation (1) Skip section navigation (2)

Re: Timezone issues with Postrres

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Euler Taveira de Oliveira <euler(at)timbira(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pratikchirania <pratik(dot)chirania(at)hp(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Timezone issues with Postrres
Date: 2011-09-21 20:31:51
Message-ID: 28648.1316637111@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Euler Taveira de Oliveira <euler(at)timbira(dot)com> writes:
> On 21-09-2011 13:38, Robert Haas wrote:
>> The rules for interpreting time zone specifications are arcane enough
>> to make me suspect that this isn't a bug even though it seems rather
>> odd, but in any case it would be useful to know how many hours
>> PostgreSQL's timestamp is behind (or ahead of) UTC and similarly for
>> the operating system.

> I think the OP is talking about one of these timezones:

It's a bit premature to speculate without knowing his exact timezone
setting, but there seem at least three possibilities:

1. The system clock is, in fact, set wrong, so that the OS is delivering
the wrong UTC time to Postgres.  This being on a Windows platform, I
wouldn't write that off.  It would be a good idea to do
	SET TIMEZONE = UTC;
and then see if now() reports the correct UTC time.

2. The timezone setting he's using is inappropriate for the jurisdiction
he's in, so that Postgres is following the wrong DST rule.  Not knowing
either his actual setting or his precise jurisdiction, this is hard to
guess about.

3. The zone data that Postgres has is obsolete for his zone.  This seems
entirely possible, although a look at the git logs doesn't reveal any
changes in Central American zone rules since 9.0.1 was released.  (I see
a change in Mexican rules listed for tzdata release 2010j in May 2010,
but that was in 9.0 beta2 and later.)  A relevant question here is
whether his jurisdiction has observed DST in recent years and then
changed their laws.

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2011-09-21 20:56:17
Subject: Re: Broken selectivity with special inet operators
Previous:From: Josh BerkusDate: 2011-09-21 20:29:23
Subject: Broken selectivity with special inet operators

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group