Re: New timezones used in regression tests - Mailing list pgsql-hackers

From Tom Lane
Subject Re: New timezones used in regression tests
Date
Msg-id 482.1399936608@sss.pgh.pa.us
Whole thread Raw
In response to New timezones used in regression tests  (Christoph Berg <cb@df7cb.de>)
Responses Re: New timezones used in regression tests  (Gavin Flower <GavinFlower@archidevsys.co.nz>)
Re: New timezones used in regression tests  (Robert Haas <robertmhaas@gmail.com>)
Re: New timezones used in regression tests  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: New timezones used in regression tests  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Christoph Berg <cb@df7cb.de> writes:
> 84df54b22e8035addc7108abd9ff6995e8c49264 introduced timestamp
> constructors. In the regression tests, various time zones are tested,
> including America/Metlakatla. Now, if you configure using
> --with-system-tzdata, you'll get an error if that zone isn't there.
> Unfortunately, this is what I'm getting now when trying to build beta1
> on Ubuntu 10.04 (lucid) with tzdata 2010i-1:

I agree, that seems an entirely gratuitous choice of zone.  It does
seem like a good idea to test a zone that has a nonintegral offset
from GMT, but we can get that from almost anywhere as long as we're
testing a pre-1900 date.  There's no need to use any zones that aren't
long-established and unlikely to change.

I'm quite unimpressed by the dependency on Mars/Mons_Olympus, too ... that
might not fail *today*, but considering it's a real location, assuming it
is not in the IANA database seems like a recipe for future failure.
Maybe something like Nehwon/Lankhmar?  Or maybe we should not try to be
cute but just test Foo/Bar.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Ignore src/tools/msvc/config.pl in code tree for MSVC compilation
Next
From: Gavin Flower
Date:
Subject: Re: New timezones used in regression tests