[jira] [Comment Edited] (OOZIE-2494) Cron syntax not handling DST properly
[
https://issues.apache.org/jira/browse/OOZIE-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16460765#comment-16460765
]
Julia Kinga Marton edited comment on OOZIE-2494 at 5/2/18 9:47 AM:
---
The failed tests are unrelated.
The long lines are from the twiki file.
The javac warnings were because the unnecessary dependency, which I already
removed. In the new results this warnings should disappear.
was (Author: kmarton):
The failed tests are unrelated.
The long lines are from the twiki file.
The javac warnings are valid. I will correct them.
> 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, 5.0.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,
> OOZIE-2494-005.patch, OOZIE-2494-006.patch, OOZIE-2494-007.patch,
> OOZIE-2494-008.patch, OOZIE-2494-009.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)
[jira] [Comment Edited] (OOZIE-2494) Cron syntax not handling DST properly
[
https://issues.apache.org/jira/browse/OOZIE-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16433546#comment-16433546
]
Julia Kinga Marton edited comment on OOZIE-2494 at 4/11/18 8:06 AM:
The problem from this issue is about the DST changes with a daily frequency.
But what about the higher frequencies? For example hourly ones?
If we apply DST correction I would apply it in every case, but in case of
hourly frequencies or even higher ones, we might have some troubles.
For example in case of an hourly frequency what is the expected behaviour? To
have an action for let`s say 1 am, 2 am, 3am in local time (Los Angeles), which
means 8am, 10am, 11am in GMT, so an hour will be skipped when DST ends, or
doubled when a DST starts, or in this case is accepted if in local time 2am
will be skipped or doubled?
Currently in case of EL DST corrections are not applied in case of
{code:java}
hours(n) or minutes(n).{code}
was (Author: kmarton):
The problem from this issue is about the DST changes with a daily frequency.
But what about the higher frequencies? For example hourly ones?
If we apply DST correction I would apply it in every case, but in case of
hourly frequencies or even higher ones, we might have some troubles.
For example in case of an hourly frequency what is the expected behaviour? To
have an action for let`s say 1 am, 2 am, 3am in local time (eq Los Angeles),
which means 8am, 10am, 11am in GMT, so an hour will be skipped when DST ends,
or doubled when a DST starts, or in this case is accepted if in local time 2am
will be skipped or doubled?
Currently in case of EL DST corrections are not applied in case of
{code:java}
hours(n) or minutes(n).{code}
> 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)
[jira] [Comment Edited] (OOZIE-2494) Cron syntax not handling DST properly
[
https://issues.apache.org/jira/browse/OOZIE-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16428169#comment-16428169
]
Julia Kinga Marton edited comment on OOZIE-2494 at 4/6/18 10:43 AM:
I have checked the coordinator functional specification and if the user don't
want any DST correction, he/she has the option to not fill the timezone or to
use UTC in the xml.
As [~rkanter] and [~jphelps] suggested, I will make here the DST adjustment
for the nominal time and I will create a separate issue for the improvement.
was (Author: kmarton):
I have checked the coordinator functional specification and if the user don't
want any DST shifting, he/she has the option to not fill the timezone or to use
UTC in the xml.
As [~rkanter] and [~jphelps] suggested, I will make here the DST adjustment
for the nominal time and I will create a separate issue for the improvement.
> 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)
[jira] [Comment Edited] (OOZIE-2494) Cron syntax not handling DST properly
[
https://issues.apache.org/jira/browse/OOZIE-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16428169#comment-16428169
]
Julia Kinga Marton edited comment on OOZIE-2494 at 4/6/18 10:28 AM:
I have checked the coordinator functional specification and if the user don't
want any DST shifting, he/she has the option to not fill the timezone or to use
UTC in the xml.
As [~rkanter] and [~jphelps] suggested, I will make here the DST adjustment
for the nominal time and I will create a separate issue for the improvement.
was (Author: kmarton):
I have checked the coordinator functional specification and if the user don't
want any DST shifting, he/she has the option to not fill the timezone or to use
UTC in the xml.
As [~rkanter] and [~jphelps] suggested, I will make here the DST adjustment
for the nominal time and I will create a separate issue for the improvement.
> 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)
[jira] [Comment Edited] (OOZIE-2494) Cron syntax not handling DST properly
[
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
[jira] [Comment Edited] (OOZIE-2494) Cron syntax not handling DST properly
[
https://issues.apache.org/jira/browse/OOZIE-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16425359#comment-16425359
]
Julia Kinga Marton edited comment on OOZIE-2494 at 4/4/18 12:08 PM:
With the fix of OOZIE-2726 a small functionality change is included for the
following scenario:
* between the start and end date there is one DST start
* the nominal time of the last action should be maximum 1h before the end time.
* this last action will not be created after the OOZIE-2726, because of the
DST correction, the nominal time will exceed the end time.
(is almost the same with the opposite scenario, when +1 action is cerated)
Note: now, DST correction is applied only for the end time.
The attached testActionMaterWithDST3.patch contains a test case for this
scenario.
was (Author: kmarton):
With the fix of OOZIE-2726 a small functionality change is included for the
following scenario:
* between the start and end date there is one DST start
* the nominal time of the last action should be maximum 1h before the end time.
* this last action will not be created after the OOZIE-2726, because of the
DST correction, the nominal time will exceed the end time.
(is almost the same with the opposite scenario, when +1 action is cerated)
The attached testActionMaterWithDST3.patch contains a test case for this
scenario.
> 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)
[jira] [Comment Edited] (OOZIE-2494) Cron syntax not handling DST properly
[
https://issues.apache.org/jira/browse/OOZIE-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16425359#comment-16425359
]
Julia Kinga Marton edited comment on OOZIE-2494 at 4/4/18 11:33 AM:
With the fix of OOZIE-2726 a small functionality change is included for the
following scenario:
* between the start and end date there is one DST start
* the nominal time of the last action should be maximum 1h before the end time.
* this last action will not be created after the OOZIE-2726, because of the
DST correction, the nominal time will exceed the end time.
(is almost the same with the opposite scenario, when +1 action is cerated)
The attached testActionMaterWithDST3.patch contains a test case for this
scenario.
was (Author: kmarton):
With the fix of OOZIE-2726 a small functionality change is included for the
following scenario:
* between the start and end date there is one DST start
* the nominal time of the last action should be maximum 1h before the end time.
* this last action will not be created after the OOZIE-2726, because of the
DST correction, the nominal time will exceed the end time.
(is almost the same with the opposite scenario, when +1 action is cerated)
> 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)
