Re: Use of recent Russian TZ changes in regression tests
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/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Reply to msg id not found: 24424.1416351230@sss.pgh.pa.us23920.1416350137@sss.pgh.pa.us