You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oozie.apache.org by "Peter Orova (JIRA)" <ji...@apache.org> on 2018/04/27 15:13:00 UTC
[jira] [Comment Edited] (OOZIE-3214) Allow configurable timezone
for coordinators
[ 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)