[ https://issues.apache.org/jira/browse/OOZIE-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16456586#comment-16456586 ]
Peter Orova edited comment on OOZIE-3214 at 4/27/18 3:12 PM: ------------------------------------------------------------- +1 for the idea [~kmarton]. Changing the semantics of the timezone tag this way in the coordinator.xml would definitely result a more natural interpretation of the tag and thereby a better user experience. Having said that, there is an area where a design decision needs to be made: what happens to the workflows that are triggered in the time interval, omitted or doubled by the DST change? h2. Example from winter to summer: Let us consider the US winter to summer change in 2018. The transition is the following: Sunday, 11 March 2018, *02:00:00* clocks were turned *forward* 1 hour to Sunday, 11 March 2018, *03:00:00* local daylight time. Question 1: * What happens to a workflow that should be triggered at 2:30 on March 11? Should it be 'forgotten'? Should it be compensated for by launching an instance at 3:00 local daylight time? h2. Example from summer to winter: Let us consider the US summer to winter change in 2018. The transition is the following: Sunday, 4 November 2018, *02:00:00* clocks are turned *backward* 1 hour to Sunday, 4 November 2018, *01:00:00* local standard time instead. Question 2: * What happens to a the workflow that is triggered at 1:30 on November 4? Should it run twice? Should the "second" execution be omitted? was (Author: orova): +1 for the idea [~kmarton]. Changing the semantics of the timezone tag this way in the coordinator.xml would definitely result a more natural interpretation of the tag and thereby a better user experience. Having said that, there is an area where a design decision needs to be made: what happens to the workflows that are triggered in the time interval, omitted or doubled by the DST change? h2. Example from winter to summer: Let us consider the US winter to summer change in 2018. The transition is the following: Sunday, 11 March 2018, *02:00:00* clocks were turned *forward* 1 hour to Sunday, 11 March 2018, *03:00:00* local daylight time. Question 1: * What happens to a workflow that should be triggered at 2:30 on March 11? Should it be 'forgotten'? Should it be compensated for by launching an instance at 3:00 local daylight time? h2. Example from summer to winter: Let us consider the US summer to winter change in 2018. The transition is the following: Sunday, 4 November 2018, *02:00:00* clocks are turned *backward* 1 hour to Sunday, 4 November 2018, *01:00:00* local standard time instead. Question 2: * What happens to a the workflow that is triggered at 1:30? Should it run twice? Should the "second" execution be omitted? > Allow configurable timezone for coordinators > -------------------------------------------- > > Key: OOZIE-3214 > URL: https://issues.apache.org/jira/browse/OOZIE-3214 > Project: Oozie > Issue Type: New Feature > Components: coordinator > Affects Versions: trunk > Reporter: Julia Kinga Marton > Assignee: Julia Kinga Marton > Priority: Major > > Right now in case of coordinators only daylight saving time corrections are > applied, the processing timezone for the coordinators is always the Oozie > processing timezone. > It would be more transparent to have an option for changing the {{timezone}} > attribute itself, such as an additional attribute in the {{coordinator.xml}} > (meaning a new version of {{coordinator.xsd}}). I would make this option > switched off by default(to have the actual behavior). > -- This message was sent by Atlassian JIRA (v7.6.3#76005)