[
https://issues.apache.org/jira/browse/OOZIE-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16427423#comment-16427423
]
Jason Phelps edited comment on OOZIE-2494 at 4/5/18 6:39 PM:
-------------------------------------------------------------
[~kmarton], [~andras.piros]
>From my point of view, I have not seen any customers who relied on, or would
>prefer the current setup where the materialized time shifts one hour either
>way when DST starts or stops. At the very least, most customers just live with
>it since that is how it works, while several have not expected that the
>materializing time would shift by an hour.
I agree with [~rkanter] that for this JIRA, it should fix the current issue
where it skips certain jobs (I.e. a daily job scheduled between 1 AM and 2 AM
will get skipped when DST ends), with a new feature to add a configurable
timezone in a separate JIRA
I would +1 an option to allow a configurable timezone ( based on normal JAVA
timezones, i.e. {{America/Los_Angeles}} ) that would match the behavior of the
EL function {{0 3 * * *}} would remain 3AM in that timezone regardless of
whether DST shifts or not) with the default behavior being the existing UTC.
was (Author: jphelps):
[~kmarton], [~andras.piros]
>From my point of view, I have not seen any customers who relied on, or would
>prefer the current setup where the materialized time shifts one hour either
>way when DST starts or stops. At the very least, most customers just live with
>it since that is how it works, while several have not expected that the
>materializing time would shift by an hour.
I agree with [~rkanter] that for this JIRA, it should fix the current issue
where it skips certain jobs (I.e. a daily job scheduled between 1 AM and 2 AM
will get skipped when DST ends), with a new feature to add a configurable
timezone in a separate JIRA
I would +1 an option to allow a configurable timezone ( based on normal JAVA
timezones, i.e. {{America/Los_Angeles) }}that would match the behavior of the
EL function {{0 3 * * *}} would remain 3AM in that timezone regardless of
whether DST shifts or not) with the default behavior being the existing UTC.
> Cron syntax not handling DST properly
> -------------------------------------
>
> Key: OOZIE-2494
> URL: https://issues.apache.org/jira/browse/OOZIE-2494
> Project: Oozie
> Issue Type: Bug
> Components: coordinator
> Affects Versions: 4.2.0
> Reporter: Dennis Pallett
> Assignee: Julia Kinga Marton
> Priority: Blocker
> Attachments: CronExpressionPOC.java, OOZIE-2494-001.patch,
> OOZIE-2494-002.patch, OOZIE-2494-003.patch, OOZIE-2494-004.patch,
> testActionMaterWithDST3.patch
>
>
> When specifying a coordinator frequency, you can also specify a "timezone".
> While the frequency is always calculated in UTC, the timezone’s DST rules are
> still applied. We can see this in the following two Coordinators, which ran
> across the DST shift (March 13 2016 at 2am) for the America/Los_Angeles
> timezone. The "el-UTC" job has "UTC" as the timezone, while the "el-LA" job
> has “America/Los_Angeles” as the timezone. Both jobs have a frequency of
> {{$\{coord:days(1)\}}}.
> {noformat}
> Job Name : el-UTC
> Start Time : 2016-03-13 01:10 GMT | 2016-03-12 17:10 PST
> ---------------------------------------------------------
> ID Nominal Time (UTC) Nominal Time (LA)
> @1 2016-03-13 01:10 GMT 2016-03-12 17:10 PST
> @2 2016-03-14 01:10 GMT 2016-03-13 18:10 PDT
> {noformat}
> {noformat}
> Job Name : el-LA
> Start Time : 2016-03-13 01:10 GMT | 2016-03-12 17:10 PST
> ---------------------------------------------------------
> ID Nominal Time (UTC) Nominal Time (LA)
> @1 2016-03-13 01:10 GMT 2016-03-12 17:10 PST
> @2 2016-03-14 00:10 GMT 2016-03-13 17:10 PDT
> {noformat}
> As you can see, @2’s nominal time is adjusted to an hour earlier in the
> "el-LA" job, but not in the "el-UTC" job.
> However, when running a similar set of jobs, but using cron syntax [({{10 1
> 1/1 * *}}|http://crontab.guru/#10_1_1/1_*_*], which indicates 1:10 every day
> of every month), this isn’t the case:
> {noformat}
> Job Name : cron-UTC
> Start Time : 2016-03-13 01:08 GMT | 2016-03-12 17:08 PST
> ---------------------------------------------------------
> ID Nominal Time (UTC) Nominal Time (LA)
> @1 2016-03-13 01:10 GMT 2016-03-12 17:10 PST
> @2 2016-03-14 01:10 GMT 2016-03-13 18:10 PDT
> {noformat}
> {noformat}
> Job Name : cron-LA
> Start Time : 2016-03-13 01:08 GMT | 2016-03-12 17:08 PST
> ---------------------------------------------------------
> ID Nominal Time (UTC) Nominal Time (LA)
> @1 2016-03-13 01:10 GMT 2016-03-12 17:10 PST
> @2 2016-03-14 01:10 GMT 2016-03-13 18:10 PDT
> {noformat}
> As you can see, @2’s nominal time are the same in both the "cron-UTC" and
> "cron-LA" jobs. The "cron-LA" job should have the same nominal time as the
> "el-LA" job from earlier.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
