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 <russell.spit...@gmail.com> 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 <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 >> > -- Ryan Blue Software Engineer Netflix
