Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan <and...@dunslane.net> writes:
Building 8.4 on a client's system, I get a regression failure
apparently due to some difference between the system's timezone DB
and what out regression tests expect, as shown below.
Those regression tests were *intentionally* set up to fail if someone's
TZ support is not Y2038 clean. This is not a bug. Advise your client
to get some less-obsolete timezone data files; or don't depend on the
system TZ database. (The only reason why you should do so is if it's
being kept up to date, eh?)
Oh, you're right, I misread the diffs. The client is getting the
machines updated.
Well, this is interesting:
and...@jimbo:~> rpm -q -i timezone
Name : timezone Relocations: (not relocatable)
Version : 2.4 Vendor: SUSE LINUX
Products GmbH, Nuernberg, Germany
Release : 31.61 Build Date: Thu 02 Apr 2009
02:31:18 PM EDT
Install Date: Wed 29 Jul 2009 10:52:55 AM EDT Build Host:
cherubini.suse.de
Group : System/Base Source RPM:
glibc-2.4-31.61.src.rpm
Size : 712873 License: BSD 3-Clause;
GPL v2 or later; LGPL v2.1 or later
Signature : DSA/SHA1, Fri 03 Apr 2009 09:20:05 AM EDT, Key ID
a84edae89c800aca
Packager : http://bugs.opensuse.org
URL : http://www.gnu.org/software/libc/libc.html
Summary : Timezone descriptions
Description :
These are configuration files that describe available time zones. You
can select an appropriate time zone for your system with YaST.
Distribution: SUSE Linux Enterprise 10 (X86-64)
And I still get these errors. Looks like at least SUSE is not keeping
up. I'll build without the system timezones.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
