Maybe separating the unit tests for this would not worth the effort.
I was thinking we should run the tests like this:
diff --git a/build.gradle b/build.gradle
index fd716e12..9b361ea7 100644
--- a/build.gradle
+++ b/build.gradle
@@ -133,6 +133,9 @@ subprojects {
}
test {
+ if (project.hasProperty("isCI")) {
+ systemProperty "user.timezone", "Asia/Colombo"
+ }
def logDir = "${rootDir}/build/testlogs"
def logFile = "${logDir}/${project.name}.log"
mkdir("${logDir}")
This would set the timezone to a specific non-UTC TZ on the CI server only.
Pros:
We know that at least once we run the tests with non-UTC timezone
By default every dev runs the tests in their own TZ, so we still test with
multiple TZs
Cons:
The TZ most often tested will change from UTC to the selected one
For me it looks like a simple change which should be ok if we want to change
the TZ.
Thanks,
Peter
> On Mar 1, 2021, at 22:34, Owen O'Malley <[email protected]> wrote:
>
> In ORC, the timezone tests vary the default timezone through multiple values
> using the Java APIs. (They do restore the initial value when the test exits.)
> :)
>
> .. Owen
>
> On Mon, Mar 1, 2021 at 9:25 PM Edgar Rodriguez
> <[email protected]> wrote:
> Hi folks,
>
> Thanks Peter for the quick fix!
>
> I do think it'd be a good idea to have this kind of coverage to some extent.
> Usually, a workflow some users follow is to only run locally the modules that
> they modify and rely on the CI to run the full check which takes longer,
> which makes room for these issues to land in master while eventually someone
> will find the broken test. However, I do agree that we probably should not
> spend a large amount of time on this - ideally if this is possible in CI
> that'd be great e.g. having two CI jobs, one for UTC and another for a
> different TZ.
>
> Cheers,
>
> On Mon, Mar 1, 2021 at 2:52 PM Ryan Blue <[email protected]> wrote:
> I'm not sure it would be worth separating out the timezone tests to do this.
> I think we catch these problems pretty quickly with the number of users
> building in different zones. Is this something we want to spend time on?
>
> On Mon, Mar 1, 2021 at 10:29 AM Russell Spitzer <[email protected]
> <mailto:[email protected]>> wrote:
> In the Spark Cassandra Connector we had a similar issue, we would
> specifically spawn test JVM's with different default local time zones to make
> sure we handled these use cases, I also would make our test dates ones on
> gregorian calendar boundaries so being an hour off with result in a timestamp
> that would end up actually being several days off so it was clear.
>
> So maybe it makes sense to break out some timestamp specific tests and have
> them run with different local timezones? Then you have a UTC, PST, CEU or
> whatever test suites to run. If we scope this to just timestamp specific
> tests it shouldn't be that much more expensive and I do think the coverage is
> important.
>
> On Mon, Mar 1, 2021 at 12:25 PM Peter Vary <[email protected]> wrote:
> Hi Team,
>
> Last weekend I caused a little bit of stir by pushing changes which had a
> green run on CI, but was failing locally if the default TZ was different than
> UTC.
>
> Do we want to set the TZ of the CI tests to some random non-UTC TZ to catch
> these errors?
>
> Pros:
> We can catch tests which are only working in UTC
>
> Cons:
> I think the typical TZ is UTC in our target environments, so catching UTC
> problems might be more important
>
> I am interested in your thoughts about this.
>
> Thanks,
> Peter
>
>
> --
> Ryan Blue
> Software Engineer
> Netflix
>
>
> --
> Edgar R
