Andrew Dunstan <andrew@dunslane.net> writes:
> But I take Tom's point about most users not knowing if their TZ database
> is usable or not. Maybe we need a tool (maybe on pgfoundry) that will do
> some analysis to find out, if such a thing is possible.
It's not really *that* hard: diff between our timezone files and the
system files will make it pretty clear. For instance, diffing a CVS
HEAD installation against a not-too-up-to-date Fedora Core 5 system
shows only a few different files, reflecting the fact that they're
different snapshots of the zic database:
$ diff -r --br . /usr/share/zoneinfo
Files ./America/Havana and /usr/share/zoneinfo/America/Havana differ
Files ./America/Santiago and /usr/share/zoneinfo/America/Santiago differ
Files ./Antarctica/Palmer and /usr/share/zoneinfo/Antarctica/Palmer differ
Files ./Australia/Perth and /usr/share/zoneinfo/Australia/Perth differ
Files ./Australia/West and /usr/share/zoneinfo/Australia/West differ
Files ./Chile/Continental and /usr/share/zoneinfo/Chile/Continental differ
Files ./Chile/EasterIsland and /usr/share/zoneinfo/Chile/EasterIsland differ
Files ./Cuba and /usr/share/zoneinfo/Cuba differ
Files ./Pacific/Easter and /usr/share/zoneinfo/Pacific/Easter differ
Only in ./US: Pacific-New
Only in /usr/share/zoneinfo: iso3166.tab
Only in /usr/share/zoneinfo: posix
Only in /usr/share/zoneinfo: posixrules
Only in /usr/share/zoneinfo: right
Only in /usr/share/zoneinfo: zone.tab
$
But IMHO the thing that you need to know to make an informed decision
is what the future update path for that system is likely to be. In the
case of me packaging Postgres for Red Hat, I feel pretty comfortable
that there will be no major surgery on glibc's timezone code within
any single RHEL release series, so if it works today it'll still work
tomorrow. A Sun engineer packaging Postgres for Solaris may be able
to make the same kind of determination. But I think Joe Average User
is sticking his neck out if he assumes such a thing for say a Gentoo
box ...
regards, tom lane
