Re: [pgsql-hackers-win32] Weird new time zone

Tom Lane wrote:
> Oliver Jowett <oliver(at)opencloud(dot)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.

It occurs to me that we should be able to automatically find a range of
dates to scan that will distinguish between all non-identical timezones
in our timezone database, and then plug the results into the scan code.

That's simplify the upgrading of timezone data anyway.. otherwise some
guesswork or hand inspection of the new data would be needed to work out
if we need to move the scan start point to be able to distinguish new
timezones.

> 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.

The install I tested on was a freshly checked out CVS tree installing
into a clean directory.

The older install had been updated and reinstalled a few times, so it's
possible it just happened to find Auckland first because of a different
ordering in the directory.

It'd be nice to have a predictable timezone choice made when there's a
tie. Perhaps we should order on timezone name in this case?

-O