Thread: Use of recent Russian TZ changes in regression tests
[ 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
Tom Lane-2 wrote > 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. The tests are intended to exercise behavior against a known set of input - in this case known TZ files. Ideally I would simply prefer to skip over (or give people a configure option) running these tests if --with-system-tzdata has been specified. The reason for the configure option is that packagers enabling this option are basically giving up some level of control or caring whether the TZ files play well with the files deployed on their users' machines. However, someone compiling and then deploying from source will like to be able to see whether their current environment pass all of the tests even if they are going to be using system timezone files instead of PostgreSQL supplied ones. I am tending to like the argument for saying date/time handling is integral to a database and thus tests should be allowed to exercise any data contained in the TZ files provided by PostgreSQL itself. I would even consider simply testing if the system timezone file is older than the PostgreSQL file and failing a test if that is the case. If that seems too harsh then testing against the earliest time we should have seen and accommodated the behavior seems like the most even-handed approach. Basically pretend we caught these nuances at the moment they came to be and wrote our test just they way we would have to write it back then. If it changes in the future we would have had to adapt anyway so no harm done. In the end having compilation or testing fail if older TZ files are present on the system AND --with-system-tzdata having been configured seems like a reasonable policy but can be separated from the issue here which is that we are fixing code to handle older data but choosing to use newer data to test said code. So I'd say we time-travel to fix the back branches and decide whether to change our policy going forward and also optionally add a configure option to control the level of validation when PostgreSQL is asked to use system timezone information instead of its own. David J. -- View this message in context: http://postgresql.nabble.com/Use-of-recent-Russian-TZ-changes-in-regression-tests-tp5827430p5827436.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
David G Johnston <david.g.johnston@gmail.com> writes:
> Tom Lane-2 wrote
>> 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.
> I am tending to like the argument for saying date/time handling is integral
> to a database and thus tests should be allowed to exercise any data
> contained in the TZ files provided by PostgreSQL itself. I would even
> consider simply testing if the system timezone file is older than the
> PostgreSQL file and failing a test if that is the case.
That doesn't make any sense as it stands, but I take your point, and
indeed that's more or less the reasoning that led me to write the test
as it is: we *should* complain if you've got TZ data that's more than
6 months old. However, the contrary opinion is that whether the user's
TZ data is too old for his purposes is not ours to decide; and that's
surely a tenable position as well.
I'm not particularly excited about allowing the regression tests to
"pass" if the test cases fail; that would obscure actual failures in
this area. I'd sooner just remove the problematic cases altogether.
Another thought that just occurred to me is that we need to test
both advance and retreat of a zone's notion of standard time, but
that doesn't mean that both cases have to be tested in the same
zone. The 2011 Russian advance is probably reasonable to depend
on by now, but maybe we could find some other well-documented case
where a zone's standard time offset decreased relative to UTC.
regards, tom lane
I wrote: > Another thought that just occurred to me is that we need to test > both advance and retreat of a zone's notion of standard time, but > that doesn't mean that both cases have to be tested in the same > zone. The 2011 Russian advance is probably reasonable to depend > on by now, but maybe we could find some other well-documented case > where a zone's standard time offset decreased relative to UTC. Ah, here we go: # Venezuela # # From John Stainforth (2007-11-28): # ... the change for Venezuela originally expected for 2007-12-31 has # been brought forward to 2007-12-09. The official announcement was # published today in the "Gaceta Oficial de la República Bolivariana # de Venezuela, número 38.819" (official document for all laws or # resolution publication) # http://www.globovision.com/news.php?nid=72208 # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Caracas -4:27:44 - LMT 1890 -4:27:40 - CMT 1912 Feb 12 # Caracas Mean Time? -4:30 - VET 1965 # Venezuela Time -4:00 - VET 2007 Dec 9 3:00 -4:30 - VET That 2007 change has the right sign (becoming more negative relative to UTC), and it seems pretty solidly documented so it's unlikely to change on us in future. Being in the other direction from Greenwich shouldn't be an issue, maybe it's even better for coverage purposes. Hence, proposal: leave the MSK 2011 cases as-is but replace the 2014 cases with comparable testing around the VET 2007 change. regards, tom lane
Re: Tom Lane 2014-11-18 <23920.1416350137@sss.pgh.pa.us> > That doesn't make any sense as it stands, but I take your point, and > indeed that's more or less the reasoning that led me to write the test > as it is: we *should* complain if you've got TZ data that's more than > 6 months old. However, the contrary opinion is that whether the user's > TZ data is too old for his purposes is not ours to decide; and that's > surely a tenable position as well. A warning would probably make sense for people compiling on their own. My point was mostly that we shouldn't be depending on TZ data (or timestamps) that is/are merely one month in the past. Luckily all my target distributions already had updated tzdata packages, so the problem was easily fixable. For me, the current case is closed, though of course the old works-even-with-tzdata-from-2010 behavior was nice to have. > I'm not particularly excited about allowing the regression tests to > "pass" if the test cases fail; that would obscure actual failures in > this area. I'd sooner just remove the problematic cases altogether. +1 Re: Tom Lane 2014-11-18 <24424.1416351230@sss.pgh.pa.us> > That 2007 change has the right sign (becoming more negative relative > to UTC), and it seems pretty solidly documented so it's unlikely to > change on us in future. Being in the other direction from Greenwich > shouldn't be an issue, maybe it's even better for coverage purposes. > > Hence, proposal: leave the MSK 2011 cases as-is but replace the 2014 > cases with comparable testing around the VET 2007 change. That would probably make sense - even when 9.4.0 comes out, the MSK 2014 change will still be very recent and might cause problems for some people. Christoph -- cb@df7cb.de | http://www.df7cb.de/