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 <pv...@cloudera.com.invalid> 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 >
