[ 
https://issues.apache.org/jira/browse/OOZIE-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Kanter updated OOZIE-2494:
---------------------------------
       Assignee: Robert Kanter
    Description: 
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.


  was:
We are using the CRON syntax for our Oozie coordinator frequencies and we have 
noticed that this has no support for DST. The DST support as described in the 
documentation doesn't seem to work for the CRON syntax.

My preferred solution would be to have coordinators that are using the CRON 
syntax to work fully within the timezone specified in the coordinator, e.g. a 
coordinator with frequency of "* 08 * * * *" with timezone Europe/Amsterdam 
(CEST, GMT+2) would run at 6 AM GMT.



        Summary: Cron syntax not handling DST properly  (was: No DST support in 
cron syntax in coordinator frequency)

Thanks for reporting this [~dennisp].  I've confirmed that the cron syntax is 
indeed not handling DST correctly, and I've taken the liberty of updating the 
JIRA with more details.

> 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
>         Environment: HDP 2.4, CentOS 7, Oozie 4.2.0.2.3.4.0
>            Reporter: Dennis Pallett
>            Assignee: Robert Kanter
>            Priority: Minor
>
> 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
(v6.3.4#6332)

Reply via email to