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 <edgar.rodrig...@airbnb.com.invalid> 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 <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 >
