[
https://issues.apache.org/jira/browse/OOZIE-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16463142#comment-16463142
]
Peter Cseh commented on OOZIE-3214:
-----------------------------------
We shouldn't be too clever about this and outsource as much as possible to
Quartz:
[http://www.quartz-scheduler.org/documentation/faq.html#FAQ-daylightSavings]
{quote}
There is one additional point users must understand about CronTrigger with
respect to daylight savings. This is that you should take careful thought about
creating schedules that fire between midnight and 3:00 am (the critical window
of time depends on your trigger's locale, as explained above). The reason is
that depending on your trigger's schedule, and the particular daylight event,
the trigger may be skipped or may appear to not fire for an hour or two. As
examples, say you are in the United States, where daylight savings events occur
at 2:00 am. If you have a CronTrrigger that fires every day at 2:15 am, then on
the day of the beginning of daylight savings time the trigger will be skipped,
since, 2:15 am never occurs that day. If you have a CronTrigger that fires
every 15 minutes of every hour of every day, then on the day daylight savings
time ends you will have an hour of time for which no triggerings occur, because
when 2:00 am arrives, it will become 1:00 am again, however all of the firings
during the one o'clock hour have already occurred, and the trigger's next fire
time was set to 2:00 am - hence for the next hour no triggerings will occur.
{quote}
We can say that if the customer changes the processing time to one with DST,
they have to manage issues like this. The alternative is to use a non-DST
processing time and have a different can of worms to deal with.
Anyhow, before deciding, let's come up with a couple of examples in a table so
we can compare our options better. I always get headache after thinking about
Daylight saving for too long :)
> 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)
