[
https://issues.apache.org/jira/browse/OOZIE-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16456586#comment-16456586
]
Peter Orova commented on OOZIE-3214:
------------------------------------
+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)
