Euler Taveira de Oliveira <eu...@timbira.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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
