Re: Use of recent Russian TZ changes in regression tests

David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)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