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
though...
What's in the database is one called "Mexico Stanadrd Time" and another one
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
America/Santiago.
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, that's
not one of them. (the bogusness mostly deals with them not properly
tracking changes in DST rules over time - they are only interesetd in rules
that are in force *today*)
//Magnus
