Pin forked test JVMs to UTC

[phdoerfler]

Datetime tests in the MSSQL suite (MovieSuite's moviesShownBetween and computed-field cases) fail on a developer machine in a non-UTC time zone, while passing in CI. The MSSQL test codec encodes an OffsetDateTime argument via a zone-naive java.sql.Timestamp (Timestamp.from(o.toInstant)), and mssql-jdbc derives the wall-clock value it binds into a DATETIMEOFFSET parameter using the ambient JVM time zone. On a UTC+2 host the filter bound shifts by two hours, admitting an extra row. Postgres is immune (native Meta[OffsetDateTime]); Oracle uses the same Timestamp codec but ojdbc binds it without the shift; CI runs in UTC so it never surfaces there.

It might be a better idea to fix this not via the build but through changing the code but I wanted to keep the mssql backend similar to the oracle backend which does not have this issue.

[milessabin]

I'm not sure I fully understand the issue here. I'm not seeing a problem with the mssql tests when I run them locally in UTC+1.

[milessabin]

I think if the issue is mssql-specific I would prefer the fix to be as well. I'm neutral on whether that should be in the build or in the test code.

[phdoerfler]

The Issue

The issue surfaces only with a timezone of UTC+2 or greater (Or UTC+1.75 I suppose). UTC+1 is not enough of a difference to trigger it because of the test data:
MovieSuite's moviesShownBetween cutoff is 2020-05-19T18:00:00Z; the nearest row in the test data past it is Alphaville at 19:45:00Z. The zone-ignoring Timestamp binding shifts the bound N hours later for a UTC+N host. At UTC+1 that's 19:00Z. That is still short of Alphaville at 19:45:00Z, so the test stays green. At UTC+2 it's 20:00Z, which crosses it by 15 minutes and admits the row.

As a result, 3 of the 14 tests of MovieSuite fail (all three moviesShownBetween variants).

The "Fix"

I did add the fix (= -Duser.timezone=UTC) to the tests of all backends purely for consistency reasons. It seemed logical to have the test environment as identical as possible between all backends and that includes the timezone. I find such environment specific influences frustrating and potentially hard to diagnose. This very issue is IMHO a perfect example. Assuming your machine is running at UTC+0/UTC+1 chances are the bug might have stayed hidden for a long time. And I fear MSSQL will not be the last backend with such a behavior.
However, I can also see an argument for keeping it to MSSQL for the purpose of discovering those differences. Either way, I think if there will ever by docs for the backends, this would be something to add there, e.g., "keep in mind, that the MSSQL driver does not respect the timezone in the same way that the postgres or Oracle backend does".

It all boils down to: uniform test environment and potentially hiding future traps like this (for better or worse) or risking a potentially different test environment between all backends which might expose additional limitations.

For now, I'll drop the system property from the other backend tests. I, too, am neutral on whether it should be in the build or the tests itself. Ultimately, it was easier to just set the property in the build so that's why it's there.

Hope this cleared things up!