Oliver Jowett <oliver@opencloud.com> writes:
> Also I'm a bit nervous about that hardcoded 2004 start date for the scan
> in pgtz.c -- that will presumably break if the timezone data files are
> updated for post-2004 changes without a corresponding change to the scan
> code.
Actually, that was intentional. My thought was that if it picks the
right zone now, while we are testing it, it will continue to pick the
right zone in future. Let's suppose we do that, and then Congress
decides to fool with the US' DST laws again in 2009. The zic people
will update their database, we will propagate that upstream change, and
identify_system_timezone will immediately fail on any machine with an
un-updated local timezone database. Now I suppose the owners of such
machines would have good reason to update their libc databases soon
... but the point is that probing future time exposes us to risks from
unforeseeable future changes, and I don't see that it gives any
advantages.
The Antarctica/McMurdo business is more interesting. I am not sure
why it picks McMurdo today when it picked Auckland before, since the
previous code certainly didn't scan backwards far enough to distinguish
those zones either. I would have thought that you'd get the first
exact match with the old code, and if the scan order is consistent
that would be McMurdo. Possibly there's some phase-of-the-moon behavior
involved in the scan order. Have you reinstalled PG without wiping the
installation directories first? If the TZ files are installed by
overwriting an existing tree, I can believe that the live directory
entries would end up in a different physical order each time you do it.
In general though, the zic database has a lot of duplicate and
near-duplicate zone entries, and I'm not sure we can hope to pick one
that the user will think is his local zone when there are several
perfect matches. (This morning I was trying to think of a way of
at least not running the calculations over again for each of several
perfect duplicates, but AFAICS we'd have to rely on noticing multiple
hard links, which would be awfully platform-dependent not to say
fragile...)
regards, tom lane