See the archived thread here:
http://www.postgresql.org/message-id/CAEghcWD8DXjroBYCZsdGrx+cHTCbCbW9es2uQ=
+o7a8NZ61JT=3DQ@mail.gmail.com
Short version: Sorry, but you're going to need to recompile if you want
that behavior. Here's a diff applied against 9.2.1
http://pastebin.com/5AyaX2RF. I've deployed the patched version a couple
dozen times now and it is working flawlessly.
T.J.
On Wed, Feb 6, 2013 at 1:32 PM, Igor Neyman <ineyman@perceptron.com> wrote:
> Timezone configuration parameter (defaulting to system timezone) worked
> fine for us before upgrading from 8.4. to 9.2.****
>
> ** **
>
> Now we=92ve got a problem. ****
>
> 9.2 Release Notes says:****
>
> =B7 Identify the server time zone during initdb, and set postgresql.conf=
entries
> timezone<http://www.postgresql.org/docs/9.2/static/runtime-config-client.=
html#GUC-TIMEZONE>and
> log_timezone<http://www.postgresql.org/docs/9.2/static/runtime-config-log=
ging.html#GUC-LOG-TIMEZONE>accordingly (Tom Lane)
> ****
>
> This avoids expensive time zone probes during server start.****
>
> ** **
>
> Question: is there any way to revert back to old behavior so that server
> will probe system=92s timezone on startup (default to OS timezone on star=
tup)
> instead setting it during initdb?****
>
> Obviously, without recompiling/rebuilding Postgres.****
>
> ** **
>
> I=92m dealing with the situation, where system is being built in one
> timezone (could be anywhere around the globe), and then moved to other (n=
ot
> known during system build) location with different timezone. ****
>
> After relocation, OS timezone will change, but we can=92t allow user to e=
dit
> timezone parameter in Postgresql.conf.****
>
> ** **
>
> Regards,****
>
> Igor Neyman****
>
