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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers