Use of recent Russian TZ changes in regression tests - Mailing list pgsql-hackers

From Tom Lane
Subject Use of recent Russian TZ changes in regression tests
Date
Msg-id 22438.1416346969@sss.pgh.pa.us
Whole thread Raw
Responses Re: Use of recent Russian TZ changes in regression tests  (David G Johnston <david.g.johnston@gmail.com>)
List pgsql-hackers
[ moving discussion from -packagers to -hackers ]

Summary for onlookers:
Bjorn Munch complained that the timestamptz regression tests added in
commit b2cbced9e failed on his Solaris machine; it emerged that he uses
--with-system-tzdata and the tzdata files on his machine predate 2014h
when the recent Russian Federation changes appeared.  The new tests
intentionally rely on the Oct 2014 Russian zone change, so the failure
is unsurprising; the question is whether we want to keep that behavior.

I wrote:
> Christoph Berg <cb@df7cb.de> writes:
>> Re: Tom Lane 2014-11-18 <1327.1416329678@sss.pgh.pa.us>
>>> Bjorn Munch <bjorn.munch@oracle.com> writes:
>>>> I now discovered that the regression test timestamptz is failing. It
>>>> has always failed on Solaris 10 due to a 2038 bug that has been fixed
>>>> in Solaris 11. But now I also get failures on Solaris 11.

>>> Hmm ... do you build with --with-system-tzdata, and if so, is the system
>>> timezone database up to date?

>> I ran into the same problem. A current tzdata version fixes the
>> problem, but it's not ideal that this is now a dependency.

>> Last time I complained about that problem, the America/Metlaka (sp?)
>> reference was changed to something older that is also included in
>> older tzdata versions. Possibly the regression tests could use some
>> older dates and not depend on Europe/Moscow from Oct 2014.

> Perhaps.  I'm not aware offhand of other cases where a zone abbreviation
> changed meaning twice; the point of the tests is to make sure the
> abbreviation decoding code can deal with such cases, so we'd need to
> find an older similar instance before I'd be happy about changing the
> tests.

I poked around in the IANA files and found some other cases where
a zone went forward and back without any DST involved, for instance
Kosrae:

Zone Pacific/Kosrae    10:51:56 -    LMT    1901        11:00    -    KOST    1969 Oct # Kosrae Time        12:00    -
 KOST    1999        11:00    -    KOST
 

That entry has been unchanged for quite some time, but so has this comment
about it:

# From Paul Eggert (1999-10-29):
# The Federated States of Micronesia Visitors Board writes in
# The Federated States of Micronesia - Visitor Information (1999-01-26)
# http://www.fsmgov.org/info/clocks.html
# that Truk and Yap are UTC+10, and Ponape and Kosrae are UTC+11.
# We don't know when Kosrae switched from UTC+12; assume January 1 for now.

So the problem with depending on this entry for testing is that if
somebody pops up and tells the IANA maintainers just when the time
switch occurred, they'll change the entry and break our test.

The one or two other cases where this happened are about as
underdocumented as Kosrae; America/Guyana is an example.

The good thing about testing with the MSK changes is that those are
quite well-documented and so we don't have to fear getting blindsided
by future updates to the IANA database.  So basically we are trading off
known short term pain (for people on machines with old TZ files) against
a risk of unexpected future pain.

My inclination is to leave the test as-is, but I'm willing to make the
changes if people would rather bet the other way.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: plpgsql - Assert statement
Next
From: Adam Brightwell
Date:
Subject: Re: Additional role attributes && superuser review