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