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 >
