Planned obsolescence in identify_system_timezone() - Mailing list pgsql-hackers

From Tom Lane
Subject Planned obsolescence in identify_system_timezone()
Date
Msg-id 15832.1214868186@sss.pgh.pa.us
Whole thread Raw
Responses Re: Planned obsolescence in identify_system_timezone()  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
I just noticed that identify_system_timezone() tries to match our
timezones to the system timezone on the basis of probing the date
range 1904-2004.  While doubtless this seemed like a good idea at
the time, it means that we'll be unable to distinguish zones whose
histories diverge after 2004.  I think there are some already,
and certainly there are likely to be some in future.  I propose
modifying this logic to test 100 years back from the current year,
instead.  Any objections?  Should such a change be back-patched?

I'm also more than slightly tempted to modify the code so that it will
always reject a match to the "Factory" zone (and fall back to regular
"GMT" instead).  The logging behavior illustrated here:
http://archives.postgresql.org/pgsql-bugs/2008-06/msg00191.php
seems just completely bletcherous to me.  It's not our business
to nag the user into setting up /etc/localtime, and even if it
were, this is obviously an ineffective way to do it ;-)
Any objections to that one?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Confusing message in log file
Next
From: Andrew Dunstan
Date:
Subject: Re: odd output in restore mode