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/
