+ 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 > > >
