"Tom Lane" <[EMAIL PROTECTED]> writes: > 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?
Seems obvious in retrospect. Or perhaps it should just always go back to about 1900 which is when a lot of places adopted standard timezones. > 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? If we're going to do it at all it should be once at startup (or config file read or some event like that). But I think I agree that it's just not our place at all and just defaulting to GMT is the right option. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
