I installed 18.104.22.168 and solved my problem. I set Windows time zone to
"Caracas" and PostgreSQL "America/Caracas" and now they both give me the
WARNING: not only people in Venezuela but also people in Bolivia is affected
by this problem. As you might recall, Windows used to have a single time
zone for both countries, namely "Caracas/La Paz". If now you set Windows
time zone to "La Paz", PostgreSQL 22.214.171.124 will use "America/Caracas" unless
you specify something else in postgresql.conf. In this case, Windows has
Bolivia's time and PostgreSQL has Venezuela's time. So people in Bolivia
should also specify timezone in postgresql.conf.
Thank you all very much for your kind support.
----- Original Message -----
From: "Magnus Hagander" <magnus(at)hagander(dot)net>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>; "Jorge Campins" <jrcampins(at)cantv(dot)net>;
Sent: Monday, February 11, 2008 4:05 AM
Subject: Re: [BUGS] BUG #3948: date/time functions returning wrong value
> On Sun, Feb 10, 2008 at 11:22:53PM -0300, Alvaro Herrera wrote:
>> Magnus Hagander wrote:
>> > Tom Lane wrote:
>> >> This does suggest that we'll need to revisit the win32_tzmap list
>> >> every so often?
>> > Seems so. It's the first time I've heard of a timezone being *added*
>> > and
>> > not just changed, but obviously it does happen :-(
>> Hmm, was this table manually built? I think I see a mistake. It has
> Yes. And it's obviously in need of updating.
>> two entries for "Mexico Standard Time", one of which (the one at GMT-6)
>> is mapped to America/Mexico_City (which I think would be correct), and
>> the other at America/La_Paz (the one at -7). This latter one I think is
> Yes, that's clearly a mistake :-( It'll only ever use the first one
> What's in the database is one called "Mexico Stanadrd Time" and another
> called "Mexico Standard Time 2". We're missing the "2" there.
>> It's hard to tell though -- I am not sure how does Windows define
>> timezones. I have always been annoyed by the fact that Chilean timezone
>> is nowhere near it's database (I think the closest is Bogota, but it's
>> really bogus because it's not even in the same hemisphere). Fortunately
>> this means there's no bogus entry for Chile in this struct ...
> My TZ database has an entry for Santiago... AFAIK, that's in Chile? -04?
> Took me less than 30 seconds to find in the GUI for the Timezone settings.
> The internal entry name is "Pacific SA Standad Time", which we map to
> Is that actually bogus?
>> I think what I conclude from this is that Windows TZ database is so
>> bogus that we should avoid trying to rely on it -- I say if the user
>> does not set "timezone" in postgresql.conf, refuse to start.
> While there are a lot of bogus things about the Windows TZ database,
> not one of them. (the bogusness mostly deals with them not properly
> tracking changes in DST rules over time - they are only interesetd in
> that are in force *today*)
In response to
pgsql-bugs by date
|Next:||From: Dave Page||Date: 2008-02-11 16:40:48|
|Subject: Re: BUG #3947: Unable to Initialize Data Cluster|
|Previous:||From: Gregory Stark||Date: 2008-02-11 15:54:18|
|Subject: Re: Adding new columns - bug|