Re: Use of recent Russian TZ changes in regression tests

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.