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

Re: REPOST: InitDB Failure on install

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Magnus Hagander" <mha(at)sollentuna(dot)net>
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-15 21:37:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers-win32
"Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
> 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:
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.

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 :-(

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.

			regards, tom lane

In response to

pgsql-hackers-win32 by date

Next:From: rodrigo.miguelDate: 2004-08-16 00:37:38
Subject: Re: REPOST: InitDB Failure on install
Previous:From: Magnus HaganderDate: 2004-08-15 21:19:34
Subject: Re: REPOST: InitDB Failure on install

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