In the beginning there was only UTC, because some users used GMT+/-N we added that config. Still it has to be a GMT time (with no DST changes).
If you want to deal with DST changes, there are coord EL functions for that, it can get complicated. I.e., to process every day at the same time, taking DST changes into account (running a report at 6AM of the current DST TZ). HTH Tucu PS: Robert, you shouldn't be working today. Congrats. On Fri, Apr 28, 2017 at 8:17 PM, Robert Kanter <[email protected]> wrote: > + Tucu, Mohammad > > The timezone attribute has been there from before my time. Perhaps Tucu > or Mohammad remembers why it's like that? As it stands, it's misleading > because we only grab the DST rules from there, not the timezone itself > (this has confused users on a number of occasions). > > If I had to guess, I'd guess that the reasons we do UTC with no DST is to > make it easier to reason about cases where you use multiple timezones, > possibly even with different DST rules, in the same Coordinator. > > I'm all for figuring out a way to make this whole thing easier. > One idea I had was to force everyone to use a single timezone with no DST > :) > > > - Robert > > > > On Wed, Apr 26, 2017 at 3:51 AM, Peter Bacsko <[email protected]> > wrote: > >> Valid point Andras. >> >> It would be great to understand the rationale behind all this. To me it's >> extremely counter-intuitive why the timezone doesn't work as it should >> (eg. >> use the actual TZ defined there, not take it from a so-called "processing >> timezone"). >> I'm sure it has an explanation though. >> >> I can imagine an improvement there - we can add an extra attribute to the >> XML like ignoreProcessingTimeZone="true" to preserve backward >> compatibility. This would actually solve DST related problem described in >> OOZIE-2494. I've created a POC for that JIRA but I don't really like that. >> Handling DST changes like that feels very hacky to me. >> >> Robert Kanter, Abhishek, Puru, Rohini? What do you guys think? >> >> Peter >> >> On Wed, Apr 12, 2017 at 4:21 PM, Andras Piros <[email protected]> >> wrote: >> >> > Hi there, >> > >> > as we all know the coordinator jobs are materialized, when frequency is >> > given w/ a Cron expression, regardless of timezone attribute >> > <https://github.com/apache/oozie/blob/master/core/src/ >> > main/java/org/apache/oozie/command/coord/CoordMaterializeTransitionXCom >> > mand.java#L471>, >> > considering only oozie.processing.timezone >> > <https://github.com/apache/oozie/blob/master/core/src/ >> > main/java/org/apache/oozie/command/coord/CoordCommandUtils.java#L801> >> > configuration entry. This is often very confusing for users. >> > >> > I think following can be done: >> > >> > - in 4.4.0 timeframe: extend the Coordinator Functional >> Specification by >> > mentioning this fact >> > - in 5.0.0 timeframe: >> > - alter functionality that timezone attribute is also considered >> when >> > frequency is Cron based >> > - make this behavior configurable >> > - make this behavior switched off by default, in order all >> > previous <coordinator-app >> > /> instances continue working >> > >> > What are your thoughts? >> > >> > Andras >> > >> > >
