Re: REPOST: InitDB Failure on install

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>, "Rodrigo Moreno" <rodrigo(dot)miguel(at)terra(dot)com(dot)br>, <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: REPOST: InitDB Failure on install
Date: 2004-08-18 18:22:15
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE34C025@algol.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers-win32

> > Hmm. There is GetTimeZoneInformation(). It returns a name, but my
> > guess is strftime just uses that one so it'll return the same thing.
>
> Probably. I did a little googling and was slightly stunned
> to realize just how little Windows knows about time zones:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-
> us/sysinfo/base/time_zone_information_str.asp
> The above struct is what is passed in by
> SetTimeZoneInformation, so evidently there just isn't any
> semantics beyond that. Ick. No wonder we were getting
> nowhere with the match-the-behavior approach --- the system
> simply hasn't got the capability to deal with the concept
> that DST rules have changed over time.

Yeah. That's what I figured from the timezone information available in
the registry as well - the BLOB is just too small.

> So I'd speculate that indeed there is only one version of the
> standard zone name and only one version of the daylight zone
> name, and in a localized Windows system it's gonna be the
> localized name :-(

I have an idea that looks like it has possibility for translating the
timezone names to english on the fly. If that one works, we can then
take the english version over to our mapping table and go from there. At
least on my swedish native installation I did yesterday in vmware it has
the information in the registry, just needs to be enumerated.
(Interestingly enough, if I install english version with swedish
langauge pack, the code appears to work as it is, which is why I didn't
find it earlier)

> Could we do anything with looking for a match to the Bias,
> StandardDate, and DaylightDate members of
> TIME_ZONE_INFORMATION, and not examining the name members at
> all? I do not know if that will give us unique matches or
> not, but it seems like the only approach that won't result in
> a vastly bloated lookup table.

See above about that idea - I think it's better if it works.

I'm not sure it'll give unique matches - I fear it won't. Therefor I'd
like to try the name match first. If that fails, we'll have to go with
the bias/date matching. If there are duplicates, we just need to pick
one of them and put out a warning.

I'll see what I can get together over the next couple of days for
testing, and we can take it from there.

//Magnus

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Andreas Pflug 2004-08-18 19:25:07 Re: [BUGS] postgresql 8.0b1 Win32 observations
Previous Message Bruce Momjian 2004-08-18 16:51:17 Re: 8.0 Beta 1 // Environment Vars // .pgpass