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 <rb...@netflix.com.invalid> 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 <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 > -- Edgar R
